Thanks for opening this PR. While you're here, there are some other changes that could be made to improve the test:

• Replace var with const where possible.
• Remove the console statements.
• Add common.mustCall() around functions that should be called.
• Maybe replace x and s with a meaningful variable name.

Hm, it looks like this is a timeout test. As much as I don't like timers in tests, it might be useful in a test of this nature.

EDIT: I just looked at the issue that this PR stems from. It is probably safe to remove this after all. Sorry for the noise.

LGTM if CI is ✅

What's the general rule for console.logs in tests? I find them often quite helpful, especially as you only see them when a test fails. Are they discouraged?

Generally console.log() output in tests should be avoided and I've removed them when I've found them. If the console.log() uses are intentional as part of the test, then a comment indicating such is helpful. The main reason I personally do not like having them there is that the extra code tends to obscure the actual test.

Generally console.log() output in tests should be avoided and I've removed them when I've found them. If the console.log() uses are intentional as part of the test, then a comment indicating such is helpful. The main reason I personally do not like having them there is that the extra code tends to obscure the actual test.

I suspect I'm in the minority on @nodejs/testing about this but:

I often find console.log() (or console.error()) messages useful. It helps to indicate why a test fails when it fails in unexpected ways. Ideally, that should be in an assert message, but that's not always possible. Also: if the failure was unexpected, there may not be an assert. (Like, if a test fails by just timing out, having a few console.log() messages to indicate where the test is hanging is useful. This is especially true if it is happening only on a particular platform in CI and someone doesn't have access to that platform locally.)

Arguing against myself, I've also seen tests that fail without log statements and then start to pass once you add the log statements. So that's an argument against the log statements. Something about blah blah buffering blah blah unbuffered blah blah flush blah blah few extra milliseconds blah blah makes the test succeed when it should fail. That's a Very Bad Thing and can be frustrating.

So, all in all... ¯_(ツ)_/¯

I don't complain when other people remove (or add) console.log() statements in a test, and I mostly avoid them myself. But I do find them useful sometimes and I generally don't ask people to remove them unless they are excessive.

CI: https://ci.nodejs.org/job/node-test-pull-request/4686/

@Trott @gibfahn ... perhaps there's a middle of the road approach we can take with regards to comments. A new common.log(...) method could be introduced that selectively generates output based on an argument or env var passed to the test runner. Default would be for the switch to be off, limiting extraneous output. Options for switching it on could include: never, always, and only-on-failure, meaning that the output would only be written out to the console if the test actually fails.

The use of common.log() within the test would be a more explicit indicator that the statement is not part of the actual test.

@jasnell I've considered that. It has its appeal. I'm not sure the additional complexity/magic in tests and resulting churn in the test dir is worth it. (Might be! I'm honestly not sure.)

CI is good except for a build failure on a Raspberry Pi which is obviously unrelated.

Landed in 611c50b