Split large Vitest suites into shards to run tests across multiple processes or CI jobs, reducing runtime and handling thousands of cases.

Run Vitest with --shard and --reporter=blob to split large suites across processes, then merge reports for a single test summary.

Sharding Solution

[00:00] You might have noticed that with every performance optimization we've had in this workshop, we're going one step higher. We started with making our test cases concurrent, then went off to disable test isolation so we don't have to pay the price for spawning the worker and thus making our test files run faster, and now we've reached the final boss of optimization, which is the process

[00:19] that runs your tests itself. And yes, a single VTOS process may also become a bottleneck in performance when it has to collect and run and report a lot of test files. So what we would like to do instead is split our big test suite with a lot of test files into shards, for example into 4 shards like here, where every shard is a separate test

[00:37] process that will be running a subset of our test files, ideally on different machines and in parallel CI jobs. That all sounds pretty nice on a graph, but let's see how sharding can improve your test performance in practice. I've got this test suite that takes 5.5 seconds to complete, because it has 500 test files

[00:55] despite all of those tests being concurrent and not having any isolation at all. So to apply sharding, I need to change how I run my tests. I will use VTOS CLI and px vtest, then run, and then provide it an option shard, and as

[01:09] the value specify what shard to run, for example, one-fourth will run one-fourth of the tests, and then two-fourth will run the second-fourth of the tests, and so on until we reach 4 out of 4. And then the other thing I need to provide is a special reporter, which is a blob reporter.

[01:27] VTOS will use this kind of reporter so it can merge the test results of different shards into a single test summary. So for example, if we run this first shard, it will run it, we will not see any kind of summary because this was only a subset of tests, and then in the report, VTOS will keep

[01:44] all the necessary information to then merge it into something more presentable for us. To give you a rough idea how these shards will be run in practice, I prepared this bash script that just runs VTOS 4 times, providing different shard index every time, so in total we are running 4 shards with one-fourth in every shard, and then just wait for all these

[02:02] runs to finish. So if I run it, VTOS will run effectively the entirety of my test suite, and then store all of those results using the blob reporter. And now to merge these results and actually see what was going on, I need to use npx vtest run and then dash dash merge reports.

[02:20] Running this command will merge all the reports from all the sharded runs and give us the complete overview. So here we can see that yes, we run the same 500 tests, for some reason the duration was 10 and a half seconds, which is twice as much as the original run. This is not something you should worry about though, because this duration is a total of

[02:38] all the per blob or per shard runs over here. And if you take a look at these, we can see that, for example, running the first shard took 2.7 seconds, and then the same for the second shard, and so forth. So roughly 2 and a half seconds per shard.

[02:55] Now if you put every shard in parallel, for example in your CI, you would be able to reduce the test run from 5 and a half seconds, initially, to 2 and a half, because all those jobs, all those different shards will overlap, providing you much faster test run. And here's an example of how you can benefit from sharding on CI using GitHub Actions.

[03:14] So I have this CI workflow that defines one job called tests, that has a strategy and a matrix in it, which are repetitive values, and having two properties here, shardIndex from 1 to 4, and a shardTotal of being 4. So we want to split our entire test suite into four parts.

[03:31] So then when we run the tests in this vtest run command, we're providing the shard option using these metric values, so shardIndex out of shardTotal. So as a result, we're going to have four different jobs, all of them named tests, going through every shard.

[03:48] And then every of these test jobs, unless it's canceled, will store the generated report in the blob format using this uploadArtifact action. We're using it so then we can refer to all those artifacts in a different job called mergeReports over here, which will wait for all the tests to finish, and then go here

[04:05] and merge all the reports using this vtest run dash dash mergeReports command to give us the overview of the entire test run. Now bear in mind that the example I've showed you is a little bit contrived. I simply don't want us to sit here and wait for a 10 minute long test run to finish to prove a point. And obviously a test run that takes 5 seconds isn't something to worry about, and definitely

[04:25] not the reason to reach out for sharding. But in your projects, especially if you have a lot of test files that have a lot of test cases taking a lot of time to complete, you will be able to benefit from sharding tremendously. Because it gives you the way to parallelize your test run on a process level, and that is extremely handy on CI-CD pipelines.

Sharding

[00:00] Another way to improve test performance when you have a lot of test files is to split those test files into groups. That approach is called sharding, and those groups, shards. Effectively, that means running multiple VITAS processes where every process focuses on its own shard. And then you can run them in parallel, for example, in different jobs on your CICD pipelines.

[00:19] In this exercise, you will explore sharding in more detail because I have another application for you that has a lot of test files. Your task will be to split them into four different groups and then run them in parallel and merge the results. And once you're done, we will talk more about sharding and how you would use it on CI, using GitHub Actions as an example.

Do you know this feeling when a tool “clicks”? When you suddenly become so comfortable with it that it’s no longer just a means to an end but an instrument to craft better experiences for yourself. Over the past decade, that transition has happened with a bunch of tools for me.

Today, I want it to happen for you with Vitest.

In this workshop, my goal is to make you a Vitest superuser. And that means stepping beyond the basics and into the advanced. That means getting so good at Vitest that you would feel confident crafting custom test experiences, understanding the inner works of your test runner, and equipping that knowledge to solve everything from complexity issues to poor test performance.

Welcome to the Advanced Vitest Patterns workshop!

## What You’ll Learn

The overarching theme of this workshop is ***customization***. I believe your experience with tools is defined by how well you understand them and how comfortable you are when it comes to customizing them. With this workshop, I’ve collected some of the best techniques and pieces of advice to make you a true Vitest superuser.

I’m also taking this workshop as an opportunity to teach you the importance of the test setup. Throughout the exercises, you will be crafting your own test experience through things like custom fixtures, matchers, and equality testers. This will help you orchestrate tests for complex, real-world applications.

### Setup

In the first block, you will get more comfortable with Vitest. From writing and debugging tests faster with the Vitest’s extension for Visual Studio Code, to configuring and visually exploring code coverage and setting up multiple test projects to use your test runner to the fullest.

### Context

You will learn how to customize your test experience by creating *custom fixtures*. Discover the fixture syntax, its life-cycle, and how to implement them in a type-safe way. Then, note down the best practices of fixture design to make sure your custom fixtures eradicate complexity, not introduce it.

### Assertions

Following the topic of customization, find out how you can supercharge your assertions. First, you will create your own matchers to help express your expectations toward your tested app and make your tests read like human language. Then, explore what is an equality tester and how you can teach the Vitest’s built-in `.toEqual` matcher to compare the incomparable.

Nail down how to write assertions for eventual states with `expect.poll` and become in full control of how much information you get out of failed assertions by understanding the balance between the hard and soft assertions.

### Performance

And yes, I’ve saved the best for last. Performance.

Learn how to profile slow test runs using built-in metrics in Vitest as well as the `vitest-profiler-plugin`. You will read the CPU and heap profiles, understand what they mean, and how you can use them to hunt down the problematic areas of your tests.

Everything past this point is techniques to make your tests faster. **We are talking up to x40 times faster** (that’s not a typo). Take a peek behind the scenes to see how Vitest orchestrates test runs and what defaults it has in place to ensure reliable results. Go through the difference between parallelization and concurrency in tests, explore the effects test isolation has on performance, and learn how to split your tests into shards for faster CI/CD jobs.

## Who Is This Workshop For

This workshop is for all developers who want to learn how to customize Vitest to create better, custom test experiences on top of it. For everyone who has felt like adding a new test in your project feels like fighting against the entire world. For everyone who has found themselves lost before a slow test suite.

As the name suggests, you will be going through advanced topics, which makes a prior basic experience with Vitest mandatory to get the most out of these exercises.

Learn advanced Vitest patterns—custom fixtures, matchers, and performance tuning—to craft faster, more effective test experiences.

Advanced Vitest Patterns 

Artem Zakharchenko

Advanced Vitest Patterns

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

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.

React Component Testing with Vitest

The Testing Bundle

Learn advanced Vitest patterns: IDE setup, multi-project config, custom fixtures, matchers, profiling, and speeding up slow test suites.

Advanced Vitest Patterns Introduction

Workshop Introduction

Boost your productivity in Vitest with IDE integration and smart config options that streamline writing and running your tests.

Setup Introduction

Set up the Vitest extension in VS Code to view, run, and debug tests directly in the editor for a smoother testing workflow.

Run tests inline, watch them continuously, and debug failed cases in VS Code with the Vitest extension for faster feedback.

Visual Studio Code extension solution

Visual Studio Code extension

Configure Vitest with multiple workspaces to separate unit tests and edge tests, each running in the right environment.

Set up Vitest with unit and edge workspaces, using node and edge-runtime environments, to test different layers of your app.

Multiple Workspaces Solution

Multiple Workspaces

Enable and configure code coverage in Vitest with the v8 provider to review test gaps and identify untested parts of your code.

Enable code coverage in Vitest with the v8 provider, generate HTML reports, preview in Vitest UI, and spot untested code paths.

Code Coverage Solution

Code Coverage

Take a short break before we dive into customizing the test context and extending Vitest to better fit your workflow.

Setup Outro

Setup

Learn how to use custom fixtures in Vitest to hide setup complexity and make your tests read like simple, focused scenarios.

Context Introduction

Extend Vitest with custom fixtures like createMockCart() using Faker to generate test data and simplify cart total calculations.

Learn how to extend Vitest with custom fixtures like createMockCart, using Faker for mock data and best practices for test design.

Custom Fixtures Solution

Custom Fixtures

Make Vitest fixtures run automatically by disabling lazy initialization—useful for global setups like mocked databases or APIs.

Enable automatic Vitest fixtures with auto: true to ensure setup and cleanup always run—ideal for mocks like databases or APIs.

Automatic Fixtures Solution

Automatic Fixtures

You’ve built custom fixtures and improved your test setup. Next up: assertions, matchers, and equality testers.


Context Outro

Context

Assertions define your expectations. Learn to write powerful matchers, clearer failures, and handle complex states with ease.

Assertions Introduction

Use custom Vitest matchers like .toMatchSchema() to validate data against Zod schemas, reducing test boilerplate and improving clarity.

Create custom Vitest matchers like .toMatchSchema() with Zod for cleaner, type-safe tests and extend expect directly in setup.

Custom Matchers Solution

Custom Matchers

Learn how asymmetric matchers work in Vitest and extend types so custom matchers like .toMatchSchema() are recognized by TypeScript.

Extend Vitest types to support .toMatchSchema() as an asymmetric matcher and validate nested objects like users in transactions.

Asymmetric Matchers Solution

Asymmetric Matchers

Implement a custom equality tester in Vitest to compare values like measurements semantically instead of relying on strict object equality.

Extend Vitest’s .toEqual() with custom equality testers, like comparing Measurement instances by semantic value instead of raw objects.

Custom Equality Testers Solution

Custom Equality Testers

Use Vitest’s expect.poll() for retryable assertions, replacing vi.waitFor() to test eventual asynchronous states more cleanly.

Replace vi.waitFor() with Vitest’s expect.poll() to write clearer retryable assertions for eventual async states in tests.

Retryable Assertions Solution

Retryable Assertions

Use soft assertions in Vitest to run multiple checks without stopping at the first failure, giving fuller feedback when debugging tests.

Use expect.soft() in Vitest to run multiple assertions without stopping at the first failure, giving fuller insight into test failures.

Soft Assertions Solution

Soft Assertions

You’ve mastered custom matchers and smarter assertions. Next up: test performance—let’s see what makes tests fast or painfully slow.

Assertions Outro

Assertions

Slow tests drag teams down. Learn how to profile Vitest runs, spot performance bottlenecks, and make test suites run faster.

Performance Introduction

Profile slow Vitest tests with vitest-profiler to identify performance bottlenecks and analyze which parts of execution take the most time.

Use vitest-profiler to generate CPU and memory profiles of your test suite, spot slow functions, and identify performance bottlenecks.

Profiling Slow Tests Solution

Profiling Slow Tests

Speed up large Vitest suites by enabling concurrency so multiple test cases run at the same time instead of sequentially within each file.

Run Vitest tests concurrently with test.concurrent to speed up large suites, configure maxConcurrency, and avoid shared state flakiness.

Concurrency Solution

Concurrency

Disable test isolation in Vitest to avoid spawning a new worker per file and reduce overhead when running hundreds or thousands of test files.

Turn off test isolation in Vitest to cut worker overhead and speed up large suites, but beware of shared state risks and possible flakiness.

Isolation  Solution

Isolation

You’ve completed the performance block. Now you can profile Vitest, understand its processes, and make smarter trade-offs for speed.

Performance Outro

Performance

You’ve finished the Advanced Vitest Patterns workshop. From fixtures to performance, you now have a stronger testing toolkit.

Advanced Vitest Patterns

Advanced Vitest Patterns

Transcript

Sharding

Transcript