Learn how to configure Vitest to handle unit tests, integration tests, and component tests within the same codebase for efficient testing.

Understand how to distinguish between unit and browser tests with Vitest workspaces for better organization, smooth execution, and easier debugging.

Multiple Workspaces

[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.

[00:00] With the configuration we have right now, Vitest will run all our tests in the browser. This may be what you want if your whole test suite consists only of component tests, but that's unlikely. In practice, your application will have multiple layers of tests, like unit tests, maybe integration tests for Node.js, and only then component tests that you should run in the browser.

[00:19] And Vitest is great for all of those types of tests, you just need to help it understand the difference between them. Wouldn't it be great if you can configure multiple test projects within the same code base? Basically, things for Node.js tests, and for your browser tests separately, still using the same testing framework.

[00:37] That is precisely your task for this exercise, so follow the instructions, update the Vitest configuration, and have all of your tests passing, because now you will have unit tests and also component-level tests from before. Give it your best, and see you once you're done.

The closer your tests resemble how your software is being used, the more confidence they will give you. There’s so many great patterns stemming from this simple rule, patterns I’m sure you’re already using to write better tests.

Then, there’s the elephant in the room. **Your test environment.**

For decades, web developers have been testing their UIs in make-believe environments that are neither the browser nor Node.js. It made them come up with a frankly ridiculous amount of test setup, polyfills, and workarounds just to make it work. Remember when you had to mock `location` in tests? `window.matchMedia`? Yeah…

It’s time to abandon such practices. The tools have improved and there’s no excuse for you to be sleeping on it. It’s time for you to learn how to use Vitest Browser Mode for in-browser component testing!

## What You’ll Learn

In this workshop, you will learn a new approach to component testing that’s both different and the same. It is different because you will write and run your tests in the actual browser, taking advantage of the standard APIs and powerful browser automation. It is the same because it’s still the component level test you know and love, with rendering, querying, and asserting. 

Your users don’t interact with the UIs you build in JSDOM. They do that in the real browser, and now your tests will too!

### **Sunsetting JSDOM**

The first step in our journey is understanding why browser-like environments fall short. JSDOM has served us well, but it's time to recognize its limitations. You'll experience firsthand how browser-like environments like JSDOM are letting you down.

We'll explore examples of valid JavaScript code that works perfectly in browsers and Node.js but fails in JSDOM, undermining the value of the tests you work so hard to write. You'll discover why these inconsistencies happen and why moving to real browser testing is the solution.

### **Vitest Browser Mode**

Vitest Browser Mode allows you to run isolated component-level tests in the actual browser while providing the convenience and flexibility of integration-level testing. It's not a full end-to-end testing framework like Playwright or Cypress, but rather the perfect middle ground for component testing.

In this module, you'll learn:

- How to install and configure Vitest Browser Mode in your project;
- The technical differences between how JSDOM and Browser Mode run your tests;
- Steps needed to migrate existing JSDOM tests to Browser Mode;
- How to set up Playwright as the browser automation provider for your component tests;
- Common setup scenarios like applying global assets in tests and configuring Vitest for both unit and component-level testing within the same project.

### **Best Practices**

Choosing the right tools is important, but knowledge that transcends any particular tool is even more valuable. In this section, we'll focus on five key areas of best practices when it comes to testing your React components:

- **Queries**: Find elements on the page the same way your users or their assistive technology would;
- **User events**: Interact with the tested elements from the user’s perspective;
- **API mocking**: Use Mock Service Worker to intercept requests and handle their responses as well as discover how to efficiently use MSW in Vitest Browser Mode by creating a custom test context;
- **Element presence**: Test elements that should (or shouldn't) appear on the page reliably without false positives or flaky results.
- **Page navigation**: Learn where to draw the line when testing page transitions and routing in the actual browser.

### **Debugging Tests**

The true value of tests comes when they fail. But dealing with failing tests can be quite frustrating without the right techniques.

In this block, you'll learn some of my favorite debugging techniques that go well beyond console logging:

- How to inspect the DOM state at any point in test;
- Using the debugger statement to stop JavaScript execution entirely;
- Wielding conditional breakpoints to step through the problematic code.

These techniques will transform your approach to test failures from dread to confidence so the next time you see a failing test you will know what to do.

## Who Is This Workshop For

This workshop is for all React developers who want to write reliable and valuable tests for their components. Whether you're new to component testing or have been writing tests for years, you will inevitably learn new tools, APIs, and techniques to gain more value out of your test suite. That’s my sole motivation behind this material.

Test React components in real browsers with Vitest! Say goodbye JSDOM’s limits and catch bugs users actually face. Real tests, real results—start now!

React Component Testing with Vitest

Artem Zakharchenko

Writing tests for their own sake is a pointless chore:

```tsx
describe('add numbers', () => {
  it('should add two numbers', () => {
    expect(add(1, 2)).toBe(3)
  })

  it('should add two other numbers', () => {
    expect(add(3, 4)).toBe(7)
  })
});
```

Another annoying testing problem is when tests are too brittle, and paint your logs red even though the application seems to work just fine.

When your tests lack real purpose or seem to fail for no good reason, it's no wonder you start to question their value.

Tests are supposed to give you confidence in your code, and save you from shipping broken stuff to prod. So why does writing them feel like such a burden?

The problem is that tests like these are focused on implementation details instead of the underlying behavior. Everyone talks about the importance of testing, but there's a lack of understanding about how to write tests that are actually useful.

How would it feel to have 100% trust in your tests, knowing that any failures are not a false alarm? What if you could seamlessly translate the underlying behavior of your application into tests that are easy (and even fun) to write?

It's possible, but it requires you to take a step back from just syntax.

In order to have the confidence you're testing the right things in the right ways, you need to dig into the underlying patterns behind the scenes of a testing framework.

This is exactly what you will do in Testing Fundamentals.

In this workshop, Artem Zakharchenko, testing expert and creator of the Mock Service Worker API mocking library, will guide you through creating your own version of the Vitest testing framework.

Building a testing framework from scratch will give you a deep understanding of how the pieces fit together, and change the way you think about testing for the better.

## What You'll Learn

The workshop is broken out into four parts, each with its own challenges and exercises that build upon the last:

### Principles

First, you'll explore the principles and mental models that underlie testing strategies. This is where you will begin to distinguish between the intention of your code and its implementation details. When you focus the intention of what your code should accomplish, you can write tests that are more resilient to change.

### Test Structure

Next, you'll do a deep dive into the structure of the testing framework. You'll create your own `expect` and `test` functions, configure your test environment, and use hooks to manage side effects in your tests.

### Testing Asynchronous Code

Testing asynchronous code requires a slightly different approach when compared to testing synchronous code. Here you'll practice with testing promises and async functions, as well as handling errors and rejections.

### Moving to Vitest

Once you've learned the fundamentals of testing and built your own mini-framework, you will migrate your tests to the Vitest framework. This process will cement your understanding of not just the "hows", but also the "whys" of testing.

## Who This Workshop Is For

This workshop is for developers who have some testing experience, but feel like they're missing the bigger picture. If you're tired of writing tests that feel like a chore, and want to understand how to write tests that are actually useful, this workshop is for you.

Testing Fundamentals

Let’s face it, mocking can be really confusing.

First, you need to know what to mock. Then, find the right way to mock that thing so it doesn’t compromise your test suite. Over-mock, and your tests become pointless. Under-mock, and they get brittle instead.

In either case, you put in so much effort, and you don’t feel like you’re getting much in return.

This is where Artem comes in. He’s been proving developer misconceptions around mocking wrong for nearly a decade, and he’s here to make you a mocking pro.

## What You’ll Learn

In this hands-on workshop, you’ll learn:

- The purpose of mocking;
- What to mock and when;
- How to write mocks that bring value instead of being a maintenance chore;
- How to separate your mocks from implementation details;
- Type safety strategies for your mocks;
- And **all the mocking techniques** you will need to test your code!

By solving targeted, real-world problems using the Vitest framework, you’ll gain a comprehensive understanding of mocking and finally unlock it as a useful tool in your testing arsenal.

## Workshop Structure

This workshop contains 6 exercise blocks dedicated to various techniques on mocking different data types.

### Boundaries

Understand what mocking really is, and learn how it helps you create test boundaries. See what each mock you introduce does to your tested code using visual metaphors.

### Mocking Functions

Functions are at the heart of JavaScript logic. Learn how to mock functions for effective input-output testing. Create mock functions, spy on function calls, and mock function implementation to tap into the right behaviors of the tested code.

### Mocking Date and Time

Eliminate the side effects of ever-changing date and time in your tests. Learn how to freeze time and mock date/time-dependent code to ensure consistent test results across different runs and time zones.

### Mocking Globals

Explore how to mock implicit dependencies, in a non-intrusive way. Learn to mock global values, methods, and environment variables to create the perfect test setup without meddling with things you don't own.

### Mocking Network

Gain control over network communication and test your client-side code reliably. Intercept requests and mock responses using Mock Service Worker. Reproduce various network scenarios, from success and error responses to offline behavior and response timing.

### Mocking Modules

Understand when to use module mocking and explore alternative techniques before you do. Learn how to mock modules in a type-safe and efficient way using built-in APIs in Vitest.

## Who This Workshop Is For

This workshop is meant for all developers, both those who are new to automated testing and those who’ve been writing tests for years. If you are unsure when to introduce mocks into your test suite, or how to do that so you don’t have to refactor it the next day, this workshop was made specifically for you.

Mocking Techniques in Vitest

Epic Testing Bundle

Learn about the world of React component testing using Vitest and discover best practices that will help you write reliable and maintainable tests for your components.

Introduction to React Component Testing with Vitest Browser Mode

Workshop Introduction

Explore the history of browser-like environments, their advantages and disadvantages, and reasons to switch to actual browser testing.

Sunsetting JSDOM

Break JSDOM

Learn about the challenges of browser-like environments such as GSDOM, how it impacts component testing, and how to utilize Vitest browser mode as a solution.

Recap Of Sunsetting JSDOM

Vitest new browser mode promotes a proper component testing strategy, allowing you to run tests in actual browsers rather than simulated Node.js environments.

Vitest Browser Mode

Learn how to install Vitas Browser Mode dependencies and configure your React project for seamless browser-based testing of your components.

Streamline your testing process by updating your tasks to utilize Vitest's powerful browser mode capabilities.

Installation and Setup

Learn how to transform your existing test cases for React components by switching from React test library to Vitest.

Get started with Vitest Browser Mode and experience improved React component testing through well-structured concepts like locator objects and streamlined element selectors.

Migrate The Test

Learn how to make your browser testing more reliable and explicit by switching from the default preview provider to PlayWrite in Vitest.

Learn how to install and configure Playwright as a browser automation tool for Vitest, ensuring more reliable component testing for your web applications.

Playwright

Make sure your component tests include the necessary styles for both visual consistency and accessibility, by updating your testing setup.

Learn how to apply styles consistently to all component tests and use a global browser setup to handle unique situations.

Shared Assets

Dive into the versatile world of Vitest Browser Remote, exploring installation, migration, custom asset loading, and best practices for component-level testing.

Outro Vitest Browser Mode

Improve your component testing knowledge through a guided exploration of accessibility selectors, user events, API mocking, element presence, and page navigation to ensure high-quality web applications.

Best Practices

Learn how to test React components by focusing on user interactions and selecting elements in an accessible way.

Queries

Move beyond basic component tasks to interact with UI elements, just like real users do, for more effective browser automation testing.

Writing test cases to simulate user interactions for applying discount codes using Playwright and Vitest.

User Events

Network Mocking

Learn how to build reliable tests for element presence and disappearance in discount form applications, while avoiding false positives.

Explore techniques to test React components using Vitest, including waiting for elements to appear or disappear efficiently and accurately without inversing assertions.

Element Presence

Learn how to create a custom wrapper function in React Router to provide the missing routing context to your isolated component tests.

Discover how to use React Router's Memory Router to achieve better test boundaries and maintain component-level test isolation.

Page Navigation

Gain in-depth knowledge of web testing best practices and lay the groundwork for successfully debugging test failures.

Recap Of Best Practices

Learn to conquer failing tests with advanced debugging techniques in this exercise focused on component-level tests in the browser.

Debugging Tests

Learn helpful strategies for debugging component tests by examining the DOM state at different points during the test execution process.

Learn how to efficiently debug your DOM issues using the debug method from Vitest, locating specific elements and fixing layout problems.

DOM Snapshots

Uncover the power of the debugger statement in JavaScript and explore how to set up Visual Studio Code for debugging and attaching to browser tests.

Troubleshoot and debug failing tests more effectively with breakpoints and debug mode, making test execution stop so that you can examine the problematic steps.

Debugger

Learn debugging features such as in-line breakpoints and conditional breakpoints, and see how they can help you tackle the root cause of complex issues in your JavaScript codebase.

Learn how to use conditional breakpoints to effectively debug issues with React components and understand their implications in your tests.

Breakpoints

Find out how to quickly deal with failed tests while increasing productivity and embracing CI pipelines using a variety of JavaScript debugging techniques.

Recap Of Debugging

Improve your web development skills by learning advanced component testing methodologies, effective debugging techniques, and how to put your newfound knowledge into practice.

React Component Testing with Vitest

React Component Testing with Vitest

Transcript

Multiple Workspaces

Transcript