I use ava to do integration tests by starting a separate node process for my express service, how should I go about correlating logs with ava?

[kevo1ution]

Context
Ava provides very nice test hooks (before, after). I use the before hook to spawn a child process which is the service that I'm testing against.
Here is a simple code snippet of how I've been trying to provide logs to AVA:

test.before((t) => {
  const server = spawn('node', ['index.js'], { env });
  server.stdout.setEncoding('utf8');
  server.stdout.on('data', (data) => {
    t.log(`server process (stdout): ${data.trim()}`); // trim to remove trailing newline because t.log adds a new line
  });
  server.stderr.setEncoding('utf8');
  server.stderr.on('data', (data) => {
    t.log(`server process (stderr): ${data.trim()}`);
  });
}

Log output of my service can be structured logs or logs that are prepended with a correlation id or cid. This cid is an id that correlates with the specific integration test I'm running which is provided via x-cid header when making requests.

What I think the problem is
It is difficult to correlate logs coming from a separate process running concurrently to ava

What I think I want as a user

1. In the test context, ava provides a unique integration test id that is maybe hashed from the t.title, and the id is accessible via t.id. I will use this t.id to put in my request headers when I'm hitting the test service.
2. Ability to call t.log with a cid that it is able to correlate and put the log with the correct test logs (interweave them). At the end of the test, it prints out the output of the logs for that test.
3. t.log should default to log output related to a file if something is calling in any of the hooks after the hooks have been completed. Right now if you log in t.before after the t.before callback finishes, that log will never be printed out.
4. t.log should provide timestamps (not as related, but I wish it provided the timestamps when outputting)

This feels relevant enough to be in ava. What do you think? I also want to avoid starting a service per individual test because that feels really bulky, but maybe I'm wrong? Any feedback on my test strategy is also more than welcome and would love get criticism to improve this.

[kevo1ution]

Also I came across this, have not tried to use it but I think I agree with the test output point https://wallabyjs.com/tech/ava/ . I heavily rely on ava so let me know how I can help too

[kevo1ution]

I ended up doing this as a work around https://github.com/turnbasedgames/server/pull/74

[novemberborn]

I've also tested services by starting them in a before hook.

However I think it's still a rather niche and specific use case, not something that AVA should provide utilities for. I would be interested in having a reporting pipeline and low-level hooks to make this stuff possible though.

1. In the test context, ava provides a unique integration test id that is maybe hashed from the t.title, and the id is accessible via t.id.

Perhaps in a world where there is more structured test output (not the default or the TAP reporters) that would be useful, but for now this can be done outside of AVA.

2. Ability to call t.log with a cid that it is able to correlate and put the log with the correct test logs (interweave them). At the end of the test, it prints out the output of the logs for that test.

This seems hard to do in a generic fashion. With better reporting internals there could be hooks into that.

3. t.log should default to log output related to a file if something is calling in any of the hooks after the hooks have been completed. Right now if you log in t.before after the t.before callback finishes, that log will never be printed out.

It's meant to be used during the hook or test execution. I see what you're saying, again we're limited by the current internals.

4. t.log should provide timestamps (not as related, but I wish it provided the timestamps when outputting)

I can see the use in specific use cases. Again with better internals and structured output this would be more worthwhile.

[kevo1ution]

Thanks for the insight!

However I think it's still a rather niche and specific use case

Yeah, totally agree here. Hopefully logging my use case for AVA is helpful to steer possible future design decisions and the product itself

structured output

Yes, this would be super helpful. I personally still need to add structured output for my logs for my services; this seems to help a ton when it comes to parsing and gleaning where to put logs, correlate them, APM, etc.