TL;DR Adjust Jest's `--maxWorkers` param and reduce your CI runtime by ~70%.

The hidden waste

On the project I am currently working on, we got used to having our CI routine taking up to 12 minutes just to run tests (understand here without any deployment nor build).

Combine this with the facts that:

- each feature pass through this process twice - once for the Merge Request and a second time before deploying

- our 4-developper team develop between 35 and 40 features a week

and you have... 16 hours a week spent waiting for tests to pass.

What about your project? How many hours a week are spent while your CI is running?

Of course one can argue that developers are not likely to stare at their screen waiting for the tests to run, but we can agree that the work done during this short waiting time will never be highly productive.

Using Jest --maxWorkers parameter

Reading Jest CLI doc teaches us that Jest CLI accepts a `--maxWorkers` parameter that "specifies the maximum number of workers the worker-pool will spawn".

This is going to interest us, since, by default, Jest calculates its maximum number of workers based on the number of CPUs your CI server has: if you have 2 CPUs (like in standard CircleCI or Travis plans), then Jest will only use a single worker. Here is the code making the calculation, from Jest source code:

However in many cases, this default value is not optimal. You can quickly check it in 5 minutes:

- Start by opening a few branches, each having a different value for --maxWorkers (1, 2, 3 and 4 for instance)

- Open a Pull Request for each, so that your CI run its tests for each of them

- You can then simply merge the branch on which the CI finishes first, and you will have the best configuration!

For my project, I had the following running times:

You can note that tests actually crashed with the default configuration, or when running with a single worker.

Hoping this will make you save your precious time ;)