Group log output with the relevant test.

[jamestalmage]

Continuation from here.

1. Use domains to determine which test console.log is used from.
2. Provide a t.log method.

2 is a less controversial choice, but won't help for logging from production code.

One possibility for such grouping would be to only display the logs when the test failed. I think this is an especially a good idea for t.log, as it lets you leave them in your tests without consequence if you think they will help troubleshoot future failures.

[vadimdemedes]

only display the logs when the test failed

I'm strongly against this one as it's very irritating when obvious & simple things (like console.log()) don't work as expected.

Domains looks like a good solution for our issues. We could also group exceptions & rejections, not just console.log()s. It was mentioned before in some issue too.

The problem with domains is this:

But if a replacement will be provided, that shouldn't be an issue to just migrate to a new API.

[vadimdemedes]

Am I crazy or we could use cluster module for that? It allows to listen to error events when worker (test) fails. Also we could attach to message events and:

console.log = function () {
  process.send(...);
};

[sindresorhus]

I'm strongly against this one as it's very irritating when obvious & simple things (like console.log()) don't work as expected.

👍 I also want them visible by default.

Provide a t.log method.

Do we really need this if we manage to route console calls correctly?

The problem with domains is this:

Domains are deprecated, but so much depend on it that they're not going to remove it anytime soon (source: Node.js core people). They don't even have an alternative yet. And the alternative is going to be powerful enough to enable building a user-land implementation of domains. More here: #214 (comment).

[jamestalmage]

only display the logs when the test failed

I'm strongly against this one as it's very irritating when obvious & simple things (like console.log()) don't work as expected.

You are probably right. I was more thinking this for t.log. My only irritation is that if I put console.log in a production file that is called by a lot of tests, I probably only want to see the output of the failing ones. Still - probably best not to.

[vadimdemedes]

they're not going to remove domains anytime soon

In that case, let's move on with domains on board.

[sindresorhus]

Am I crazy or we could use cluster module for that?

I'm not really familiar with the cluster module.

[jamestalmage]

Do we really need this (t.log) if we manage to route console calls correctly?

My thought was that it would be similar to console.log, but hidden unless the test fails.

cluster

That only gives you per-process resolution. We need domains to narrow it down per-test

[vadimdemedes]

@jamestalmage I actually thought about running a worker per test. I just realized it's completely insane.

[vadimdemedes]

Mind wonders when you're desperate :D

[jamestalmage]

I actually thought about running a worker per test.

It's crossed my mind, and I definitely don't think it's insane, but probably not very performant.

[sindresorhus]

I actually thought about running a worker per test.

I considered that a year ago, but decided not to open an issue about it as it would come with a lot of overhead. Might be something worth exploring at some point as totally isolated tests would be so nice.

[sindresorhus]

You are probably right. I was more thinking this for t.log.

That's kinda what the message arguments in assertions are meant for, but I guess it could be useful for generic debug stuff when it fails. Not sure .log is the best name for something like that, though. Maybe t.debug(), which is shown when a test fail or in debug mode?