00:00 To tell Vitas that it should run some of your test cases concurrently, you have to change the way you declare your test. From the test function to test.concurrent function. Introducing this change will let Vitas know that this test case is concurrent. Because I'm creating test cases in a loop, it means that every test case created will be concurrent.

00:18 Now, when introducing concurrency to my test suite, I need to be extra careful not to have any shared state that would cause my tests to be flaky. And sometimes even the expect function itself can have state. So I'll make sure to access the version of that function that's bound to a particular test case by grabbing it from the test context and then using it normally.

00:38 Once I've done this, I will refactor the second test case as well using the same approach. So test.concurrent and then accessing the expect function. And let's run the test to see what kind of impact this change has. So we just went from almost a three second long test run to 750 milliseconds instead. That's a huge improvement.

00:57 But we can actually do better. By default, Vitas will run five tests in the concurrent mode at the same time. And you can configure how many tests it can run that way by going to the Vitas configuration to the test key over here and setting the max concurrency option to the number of tests you want to be run concurrently.

01:15 The maximum number of tests at a given point of time. For example, if I say 50 and rerun the tests, now I went from 750 milliseconds to 270. And that is also another performance boost. Let's take a look at what's actually happening to our test suite once we switch it from the sequential run to the concurrent run.

01:34 By using test.concurrent, we're effectively negating this test case waterfall and make all test cases run at the same time. As many test cases as you have defined as the max concurrency value in your config. So it can be 50 or maybe it can be just two at the same time. That is also fine. It is extremely important to understand that concurrency itself is not a solution to any

01:53 problem. It is simply a change in how Vitas runs your tests. And despite that change yielding obvious performance benefits, it comes with a cost. Because when you opt out from this default sequential test case waterfall, you're telling Vitas, hey, I've got the isolation of my test cases covered. You don't have to worry about me, which also means you have to have it covered.

02:12 So no more shared state between tests or unmanaged side effects and in general, self-contained and isolated test cases. Achieving that requires time and effort, but this is also a great example of how paying due attention to your testing strategy from the get-go pays off in the long run. So you're able to benefit from things like concurrency and other techniques that we're

02:31 going to go through in this block. But it doesn't mean that you need to have a perfect test suite through and through to start benefiting from faster tests. You can introduce concurrency incrementally, starting from your unit tests that are often self-contained by design and then slowly making your way through the rest of your test suites on a test per test basis.

02:49 One great side effect is that switching your tests to concurrent mode will often highlight any problem areas you might have with those tests. And once you know a problem, it's much easier to fix it.