run Mocha's tests concurrently

[boneskull]

I don't see why we couldn't leverage something like concurrently to run our Node.js-based tests concurrently, since we have to invoke Mocha many different times for each type of test.

[osalama7]

We run integration tests, unit tests with Mocha and it takes up to 36 mins to finish all the tests, Which is primarily an issue with how the tests were written in the first place, discrete, and repeating the same operations in different tests
Solutions include a more outlined test sets, with possible utilisation of global variables available for similar tests, and finally how to run tests in parallel, Also would like to follow up on this issue, and appreciate any input to help reduce runtime of tests

[ORESoftware]

This is harder to implement than it sounds, because of features that you will want to add once the basics are hooked up.

I have this shell script utility that runs shell commands in parallel, waits for all to exit, and exits with code 0 only if all subshells exit with 0

https://github.com/ORESoftware/generic-subshell

[bajtos]

We are interested in this feature for LoopBack too. Our main development is happening in https://github.com/strongloop/loopback-next, a medium-sized monorepo.

Few comments from the experiments I did so far using https://www.npmjs.com/package/mocha-parallel-tests:

• The module uses worker threads on Node.js 12+ and child processes on older versions. Are failing when run via worker threads, because our CLI tests are calling process.chdir, which is not supported in worker threads. process.chdir is changing the current working directory, which is needed because of the way how Yeoman works. (Our CLI is implemented via yeoman generators, unfortunately.)

• LoopBack is very expensive to load. At the moment, our Todo example application takes 1.4s to 2s to load. If you spawn a new child process of every test file, then the tests will spend most of the time inside require. I have verified this via mocha-parallel-tests, where our tests took several times longer to complete when run in parallel.

• Regarding node-tap: That framework is running each test file in a new process from the beginning, so the users must have already accommodated for the fact that every test file is going to load their module from fresh. Switching from serial to parallel execution is less disruptive.

For Mocha and loopback-next, it would be ideal if the same child process could be re-used to run multiple test files. For example, the "master" process can spawn multiple child processes and then fan out test files to run to children one-by-one. When a child finishes running a test file, it can signal the results to master and master can send it another file to run.

By re-using child processes this way, I think there will be less (if any) need to switch from child processes to worker threads, because there will be a fixed & small number of child processes to spawn at the beginning.

A more complex problem is how to deal with global before/after hooks. Some global hooks are initializing in-memory artifacts, those need to be executed once in each child process. Other global hooks may be touching global state (e.g. resetting & seeding up the test database), we may need to run them only once per test run.

[SeekDaSky]

Seeing there are efforts being put into this I'd like to submit a slightly different use-case.

I am using mocha to execute browser automated tests (using playwright). In those tests almost every single method is async and each test run in their own "private" browser tab (ie. technically all the tests could run in parallel without any issue).

This use case does not need other background threads to execute tests concurrently, as most of the time spent in tests is waiting for the browser to do an action.

If concurrent execution is added to mocha it would be great to have a way to execute tests concurrently but on a single process.