00:00 Similar to concurrency, disabling test isolation is a small change with huge impact, but not without its price. To opt out from the default test isolation, and stop VTEST from spawning worker for each test file, go to your VTEST config, and in the test object, set the property isolate to false. Now, let's see what kind of impact it has on our tests.

00:19 So let's run them with npm test, and you can see that we went from 7 seconds to 600 milliseconds. This is a huge performance boost, but let's not forget that it's not free. In fact, let's take a look at what actually changes once we set isolate to false. So with this change, instead of running in its own isolated environment, every test file

00:39 will now run in the same process, sharing that environment. Because of this, it makes much easier to introduce shared state between test cases, which will result in flakiness. And this is another reminder for you that similar to concurrency, disabling test isolation doesn't solve any problems, it changes how VTEST runs your tests.

00:56 Keep in mind that by setting the isolate property to false, you're affecting your entire test run. But that doesn't mean you cannot opt out from this default incrementally. In fact, you can leverage the projects or workspaces feature in VTEST to create a new test project that will only target a subset of your tests, and you can disable the test isolation there, just for those tests.

01:15 It will make it easier to introduce this into your test suite, or maybe apply this only to the tests that will benefit the most out of it. You can make your tests concurrent, and you can turn off the isolation, but you don't have to. Basically, you are the best judge whether that's needed. So play with those options and see how they affect your tests, and also what kind of issues they help surface.

01:34 And I know these changes require a lot of effort, but I firmly believe that every right decision, no matter how hard, makes the next right decision much easier.