For the remainder of this exercise block, I would like for us to focus on techniques to apply to performance issues caused by a large number of tests. Even if every single one of your test cases is blazingly-fast, if you have a million of them, your test run will still be slow.

One of the ways to fix that is by utilizing concurrency.

But before that, you need to understand how Vitest runs your tests.

By default, Vitest runs every test file in parallel and every test case (within the same test file) in sequence. You can visualize your test run like this:

Both suite-a and suite-b will run simultaneously in different workers, but test cases inside them will run one after another. In the end, your test run is only as fast as your slowest test suite.

These defaults are intentional and are designed to prevent flakiness. Vitest can afford to run test suites in parallel because each test suite runs in a separate worker (again, by default). Workers share the test environment but nothing else, which makes it safe to run them at the same time.

On the other hand, all test cases within the same test suite run in the same worker. Here, the risk of shared state is higher, and so Vitest defaults to running them in sequence to prevent test cases from stepping on each other's toes.

Both parallelism and concurrency can be configured in Vitest and in the right test suite can give you a significant boost in test performance. It's time you learned how.

If you run npm test, you will notice how slow our test suite is:

 ✓ src/one.test.ts (100 tests) 2644ms
 ✓ src/two.test.ts (100 tests) 2644ms

 Test Files  2 passed (2)
      Tests  200 passed (200)
   Start at  12:24:45
   Duration  2.91s (transform 25ms, setup 0ms, collect 25ms, tests 5.29s, environment 0ms, prepare 65ms)

It's not slow because tests are slow individually. It is slow because there are 200 tests in total, making the test run last a soul-crushing 3 seconds.

👨‍💼 Your task is to improve that time by using concurrency. Head to those two test files and follow the instructions to make their test cases concurrent. Once you're done, run the tests again and see if you can spot a difference.