00:00 In Vitest, you can define multiple test projects with their own file patterns and configurations using a feature called workspaces. This is how you do it. I'm in my Vitest config and the first thing I'll do is comment out these options for browser tests. We will still use them but a little

00:15 bit later. To define a workspace, add this test option again and inside it, add the workspace option. The value for this option will be an array. This will be the list of Vitest configurations representing your different test projects. So in that case, we have two projects, one for unit

00:31 tests and one for the browser tests. Let's define the workspace for the unit one. So here I'll add an object, this will be my Vitest config, and again add the test key and give this workspace a name unit. Notice that although we already nested under test workspace, I'm defining this configuration as

00:47 if I'm defining it from the very root of the config. This is intentional. This is done so that you can define different options for different workspaces overriding the root options. This is really handy because this way you can provide different configurations or different plugins, for example, that are relevant in the context of this workspace. So then let's add options like

01:06 globals because I want functions like test and expect to be available globally during the test run. Also define the environment for these tests. In this case, I want my unit tests to run in an OGS environment. And the last remaining thing is to define which files should be considered unit

01:22 tests. So I will do that by providing an option called include and specifying the pattern here for my unit tests. It will be src matching test dot ts. With the addition of unit tests, we're basically introducing a new TypeScript file pattern. So let's make sure that TypeScript knows which type context is relevant for those unit tests. For example, so you wouldn't be able to

01:42 access types like document or window in your unit tests that run in OGS. To do that, head to the root of your app and create a new configuration for TypeScript called tsconfig test unit dot json. This will be a TypeScript configuration for unit tests and pass the following options. What we're

01:59 doing here is extending our base TypeScript configuration, then providing the include property to make sure that this configuration only matches our unit tests. This is the same pattern that we use in the workspace. And then the compiler option types specifies which types are available globally for these unit tests. So first, I want node.js types to be available, of course,

02:18 because these tests run in node.js. This is the package you have to install in addition. So if you don't have it, make sure to run npm install types slash node. And then finally, the vitas globals definition. So global functions like test and expect have correct types. Now that we have this new TypeScript config, let's make sure that TypeScript actually picks it up. So again, at the

02:38 root of your project, open your tsconfig dot json, the one with this references, and let's add the reference to our unit tests here. So test unit. So this will make sure that TypeScript picks up this new configuration when it applies types and validate types and whatnot. So our unit test

02:53 workspace is complete. Now let's define one for our browser tests. So in a workspace area, I will add another object for our browser test configuration. I will copy the options we had before these ones because they still apply. I'll paste them here. There's a couple of things I need to

03:08 change though to make sure that this config works well in context of workspaces. First, on the root level of this workspace, I will add an extent property that equals true. This is going to tell vitas to merge this workspace configuration with the root level configuration of my app.

03:23 So in this case, it will inherit things like plugins for React and Tailwind. And once again, bring closer our production environment and test environment. This is a really great thing you should benefit from if you're building Vite apps. So next, let's also give this workspace a name by defining test name property, and I will give browser here as the name for this workspace.

03:43 And of course, let's define which tests are considered browser tests by providing the include property and providing this pattern over here that will match the test ending when browser.test.ts or tsx. Now that we have this component test pattern defined, let's also rename our existing

03:58 component tests. So in the project, I will head to this file preview test and rename it to have the suffix of browser.test.tsx. That's just nice. Now that we've adjusted the file pattern for our component tests, our existing TypeScript config that covers them doesn't make sense anymore.

04:17 So let's change it. Let's open it. This is TypeScript.tsconfig.test.json. And here let's provide the proper file pattern now to include browser test over here and also rename this configuration to be more in line with what we did with unit tests. So I will rename this one to

04:35 test.browser.json. And once again, because we renamed this config, let's make sure to update the root level config here at tsconfig.json to reference the new browser config like this. And with this, our browser test workspace is complete. In my workspaces, I'm differentiating

04:52 between the unit tests and the browser tests based on the file pattern. But you can also use different approaches, for example, based on the directory where you put your tests. What matters here is that you stay consistent no matter what you choose. If I take a closer look at my patterns, I can see that the include pattern for unit test actually overlaps with the one for browser tests.

05:12 And it's not what I want. So to fix this, I need to exclude browser tests explicitly from my unit test workspace. I can do that by going to this workspace config and providing the exclude option over here. And I will copy the pattern that matches browser tests and paste it here. There's

05:29 one more thing to be aware of. Once you're providing these options, Vitest will take them as is. So in this case, this exclude area only has one pattern and it loses the default exclude patterns that Vitest provides, for example, to ignore everything in node modules. To bring the behavior back,

05:45 let's head to the top of the file and import from Vitest slash config, import the object called config defaults. This object contains all the default configuration for Vitest and we will use

05:57 it to go to our exclude pattern here and spread the default value for exclude. This will make sure that we are layering on top of default Vitest behavior to now exclude the browser files from our

06:11 unit tests. Now we have our two workspaces defined, so let's see how we can run the tests. To run a particular workspace, use the Vitest CLI and provide the option called project. And as the value for this option, provide the name of the workspace you want to run. So for example, I can provide the unit

06:28 name, which will run the unit test here because my unit workspace is called like that. So once I run this, I will see the results from my unit tests. In this case, there's one test for read file function and I can see the output for it down here. So the same applies to the browser tests. Let's provide a different project name. So our browser tests are called browser. So let's provide

06:47 it here in the CLI and this will spawn the play right here and we can see our browser tests running as well. And finally, you can run all of these workspaces at once just by running Vitest. Notice that this also spawns this graphical interface, but this doesn't mean that everything

07:05 here runs in the browser. You can see Vitest actually lets you know that this test was run in the browser in Chromium. This is our instance. And these tests here are unit tests. You can just use this graphic interface for better debugging and just better navigation through your test suite.