[Feature]: Run every test in a separate worker

[rix0rrr]

🚀 Feature Proposal

I'm asking for some flag that allows us to (incidentally) run every test in a different worker (as opposed to all tests from a single file sequentially in the same worker).

A thing to decide would be how to handle beforeAll()/afterAll(), but I think it would make sense to run both of these in every worker.

Effectively I think it should be equivalent to running:

$ jest file.test -t 'test 1' &
$ jest file.test -t 'test 2' &
$ jest file.test -t 'test 3' &
$ jest otherfile.test -t 'test 1' &
# etc

All in parallel. Those commands would execute beforeAll()/afterAll() for each test, so I think this new mode should do the same.

Motivation

In a large and complex code base with a large team of varying skill levels, it is easy to accidentally write tests that depend on each other's execution.

Without proper discipline, it is somewhat easy to write tests like:

test('test 1', () => { 
  // Does something with a mock, or some global state that might not be ovious
});

test('test 2', () => {
  // Has accidentally been written to succeed only after 'test 1' is run
});

These kinds of issues are a pain to track down: test 2 will appear to work fine, until it is run in isolation (or in a subset of tests), and then it will fail.

Running all tests in isolation will be an easy sanity check to see if the tests are properly isolated, and could be run in any order and in any parallelization setup.

I'm not proposing this mode would be used on every run (because obviously there would be performance implications), but it can be used to diagnose test isolation issues if you suspect them. You would run:

$ jest --all-tests-isolated

Or something, and the failing tests would give you a good idea of where to continue investigating.

Example

No response

Pitch

Writing good, isolated tests is an important skill to learn for every developer.

Having a feature in the core gives it visibility, easy access gives it a chance that it will be used. When it gets released, blog posts will get written about the new feature, and junior devs will find and read those blog posts and have a new concept of the importance of this and a tool in their toolbox to attach it.

I suspect that relegating this to a plugin is probably possible, but it will only get uptake among those few who have been bitten so often that they know to look for it. That doesn't nearly move the profession forward as much as having it front and center would.

[mrazauskas]

You should try the randomize option. Running tests in an arbitrary order can also help to catch the ones which depend on each other.

[rix0rrr]

D'oh, can't believe I missed thank. Thanks!