Allow child processes to inherit stdio streams

[jamestalmage]

When writing native-stream-type, I had to abandon AVA as my test runner because it hijacked the native stdio streams (which I needed access to for testing).

While we have good reason for doing this with the default reporter, I don't see why we need to for the verbose reporter (and maybe even tap).

For those reporters, we could just fork like so:

// verbose
childProcess.fork(path, args, {
  stdio: 'inherit'
});

// tap
childProcess.fork(path, args, {
  stdio: [process.stdin, process.stderr, process.stderr]
});

The verbose reporter would allow test processes to fully inherit all streams from the parent - ideal for my situation.

The tap reporter would still need to redirect all output from the child process to stderr in the parent, but at least you've still got native TTY streams in the child then.

[sindresorhus]

Inheriting comes with some downsides though. We would not be able to consume or transform the output at all.

Another solution would be to add an option to not spawn AVA test files as child-processes. Pretty much what ava/profile.js does now. I also need this for testing Electron apps, as their tester needs to inject some globals. Having such option would also fix our React/etc performance issues. Thoughts?

---

Relevant: sindresorhus/np#136

[jamestalmage]

Inheriting comes with some downsides though. We would not be able to consume or transform the output at all.

But we don't do either of those things for either the tap or verbose reporters.

Another solution would be to add an option to not spawn AVA test files as child-processes

We should make that an option regardless. Not sure it would improve performance all that much.

[sindresorhus]

But we don't do either of those things for either the tap or verbose reporters.

Right now we don't, but we might need it to be able to place console output together with the correct test when running concurrently, although there might be other workarounds. Another issue is that it will create different environments for the verbose and default reporter. So a test might fail with the default reporter, but pass with the verbose reporter.

We should make that an option regardless. Not sure it would improve performance all that much.

I'm pretty confident it will, but we won't know for sure until we try.

[sindresorhus]

Another solution would be to add an option to not spawn AVA test files as child-processes. Pretty much what ava/profile.js does now. I also need this for testing Electron apps, as their tester needs to inject some globals. Having such option would also fix our React/etc performance issues. Thoughts?

@novemberborn Any thoughts on this? I would really like to see this happen.

[novemberborn]

Another issue is that it will create different environments for the verbose and default reporter. So a test might fail with the default reporter, but pass with the verbose reporter.

👍 Reporters shouldn't impact tests.

Another solution would be to add an option to not spawn AVA test files as child-processes.

I can see that, though it would have to be a global option (apply to all files). I think we'd need more refactoring to make this work, and perhaps run the test files in a new script context rather than directly in the global.

[novemberborn]

I had to abandon AVA as my test runner because it hijacked the native stdio streams (which I needed access to for testing).

This might not be great for performance but presumably those tests would also work if the test spawned yet another child process which executed a fixture?

[sindresorhus]

I can see that, though it would have to be a global option (apply to all files). I think we'd need more refactoring to make this work, and perhaps run the test files in a new script context rather than directly in the global.

Yes, should be a global option and I was also thinking of it using the vm module.

[jamestalmage]

This might not be great for performance but presumably those tests would also work if the test spawned yet another child process which executed a fixture?

Nah, they grand-child process would still get a pipe instead of a tty type stream. TTY is only available in the top level process (and only when launched from a console), and to any descendants that get their stdio streams with the inherit option. Once a child has a pipe type stream, a grandchild that inherits from it will still get a pipe type stream.

[jamestalmage]

RE: global option

That would suck for a large test suite if you only needed it for a few tests. It would be nice to address some configuration options on a per test basis. I'm thinking this option, fail-fast, serial, and require:babel-register, etc. What if we wrote a Babel plugin that allowed you to export a config in your test:

export const avaConfig = {
  serial: true,
  failFast: true,
  require: ['babel-register'],
  runTopLevel: true
};

Computed values wouldn't be allowed - that way we could interpret it via a Babel plugin without actually running the test file.

[sindresorhus]

@jamestalmage Can you open a separate proposal (issue) about it? Another solution could be to have config overrides like in XO.

[sindresorhus]

I split the "same process" discussion into a new issue: #1332