lorenzofox3 / zora

Lightest, yet Fastest Javascript test runner for nodejs and browsers
MIT License
539 stars 93 forks source link

Async iterator for tests #152

Closed wokalski closed 1 year ago

wokalski commented 2 years ago

This is just an example, not a working implementation to give you an idea of what I mean. Feel free to take it from here if you have a moment. I'm just not that well versed in zora.

wokalski commented 2 years ago

I just looked at the implementation of this library and it won't actually work unfortunately because it's lazy but I hope you get the idea.

lorenzofox3 commented 2 years ago

I am not sure this would help much.

Trying to be a bit more clear

Zora collects the tests and execute them eagerly at the same time. The execution of a test may consists in collecting new sub tests. This should not impact the reporting as the reporting stream is eventually blocked when the test under report at the moment in the stream has not completed (but all the other tests are still running concurrently, just the reporting is blocked)

It then starts the reporting at the end of next tick (or when all the scripts have loaded in the browser): which "normally" should allow any test and sub test (asynchronous or not) to be collected. This is just for convenience so the reporting auto starts without the need of any runner and I don't want the process on "how file are loaded" to leak in the library itself (it is the job of the test runner).

If for some reasons you want to control when the reporting start (because you load the test files yourself for example) you can "hold" the reporting stream and start it whenever you want (again this does not prevent the tests to run in anyway): that's what pta does (and it does not do much more at the end). So any "fix" should probably go at the level of the test runner (pta in this case)

If you want to try a patched version of pta you can simply replace this line in your node_modules by

process.on('beforeExit', () => {
  report({
    reporter: reporterInstance,
  });
})

And your problem should be solved.

We could introduce this patch but my concern is:

as you hook the reporting on the beforeExit, the reporting will start only once the program is about to exit: ie after all the tests have completed, and that is not ideal.

wokalski commented 2 years ago

I pushed what I had in mind but it creates a chicken and egg problem. The tests stream waits for new tests and the exit of the program waits for the tests stream iterable.