Concurrent suites execution

[emdin]

Hello,

do you have a concurrent suites execution on the project's roadmap? It can be really beneficial for headless browsers like Zombie.js, which can be spawned and executed in parallel. At the moment Mocha runs suites one by one, so there is no gain from having multiple headless browser instances.

[scott2449]

I would like this ability in theory as well but after thinking on it a bit it would require a bunch of complexity to keep meaningful reporting output. You can use something like gulp-spawn-mocha to run a bunch of separate files in parallel but then you wind up with separate reports (and only if you use a file based reporter, real time reporters give the same mess)

Did you have any ideas for addressing that @emdin ?

[emdin]

@scott2449 hmm I think I miss something. What I had in mind is suites run concurrently ("thread" per suite) and there will be the same final report (5 passed/2 failed). So we'll have he same reports but with undefined order. Since suites identified by their names it shouldn't be a big problem.

[scott2449]

@edmin I was saying that I agreed with you but that it doesn't work at the moment. There are currently some concurrency issues with mocha. When tests are run async (which you can do with programatic execution) some data, like file names, gets all screwed up. Also most reporters are currently real time, like spec, and just interleave all the results.

[emdin]

All right, now I understand. I somehow made it work with node.js using domains, but it is not production ready of course.
But do you think this feature will be useful for Mocha users or may be my use case (Zombie.js tests) is too specific?

[boneskull]

This issue has been raised many times, implemented, then removed, because it was too complex and didn't end up buying people much time.

[danielstjules]

I just started using this with acceptance tests: https://github.com/danielstjules/mocha.parallel

[ORESoftware]

@emdin if you are still working on that let me know, I found domains as being the only way to solve the problem of handling errors thrown from async tests in any given suite