00:00 There is a lot of confusion when it comes to parallelism and concurrency in test runners. So let's clear it once and for all by returning to our fabulous diagram. Let's take a closer look at this workers part. I will just copy these, a couple of these, and I'll move them here. We will examine them in more detail.

00:15 So first thing to understand is that Vitess runs each test file in its own worker. So I can have a like 1.test.ts and I can have 2.test.ts. Each test file will spawn its own separate worker and those workers will run in parallel.

00:34 And this is your default parallelism in Vitess. But when Vitess runs test cases within those test files, things are a little different. Allow me to expand this 1.test.ts and let's say this test file has three test cases.

00:47 So what Vitess will do, it will run the first, then the second, and then the third. They will not be parallel or concurrent, they will run sequentially. The fascinating thing about these defaults is that they make sense and they actually help you write better tests.

01:03 Workers run in parallel because each worker is a separate, standalone, and isolated environment that cannot overlap. Unlike the test cases that will run in the same environment. So if one test case introduces a shared state and it mutates something that a default test depends on, it will break the test.

01:19 To prevent that, Vitess runs them one by one by default to minimize the amount of flakiness you get due to the shared state and other issues. But sometimes it's important to know when and how to opt out from those defaults. And I have just the use case in mind. If you head to your Playground directory and run the test with npm test, you will see this

01:37 two test files running, and it takes some time, and then the run is done, and it took almost three seconds to complete. You may notice that I only have two test files, but each test file has a lot of test cases inside, 200 in total. And that takes time because Vitess runs every test case sequentially.

01:56 And it produces this test case waterfall, and that results in a slow test run. And your task in this exercise is to improve the test performance by refactoring the test cases from sequential run to concurrent run. And once you're done, we're going to talk more about concurrency, when you would use it, and what is the price you have to pay for it.