Set up MSW

[00:00] Let's add an automated test for a getUserToken function to verify our MSW setup. We'll create a test file called getAuthToken.test.ts and quickly paste this little test here. What it does, it calls the getAuthToken function providing it with some credentials, but it doesn't even have any assertions just yet.

[00:19] Now let me try running this test by npm test. I can see that the test is failing. That's because we're not handling any requests in our handlers just yet. But if I scroll above, that log message looks extremely familiar. Well, this is precisely the log from here, from our request handler, that prints the request method and request URL.

[00:42] But how does MSW know that this request has happened? Let's go through it. So in our code, where we're making this request, our code will actually perform this fetch request and it will trigger MSW's interception algorithm. And since we have it enabled right here with server.listen in our Vitas setup,

[00:59] it will start looking up for any matching handlers for this intercepted request. So it will see this first handler, which is matching because it matches all the methods to all the paths, and it will print this. It will execute this whole resolver, printing this console message in our test output. So as you see, we're able to trigger this request handler,

[01:20] but it doesn't actually handle the request yet. Let's learn how to return a mock response in the next exercise.

[00:00] Let's learn how to set up MSW together, so feel free to follow me while you're watching this video. So here we have a getAuth token, and the purpose of this function is to fetch some authentication token from somewhere, to be specific from this made-up server URL. And then it has some response handling, some basic error handling, and in the end reads responses.json and returns the

[00:19] fetched token. So obviously we want to mock this fetch request for two reasons. First, to draw this test boundary between this function and its test, and the actual server. But then also to gain control over what the server returns, so we're able to tap into all of these different behaviors

[00:38] during the tests. So I will start from installing MSW. In the terminal I will run npm install msw. This is going to add mock service worker as a dependency to your project. It's going to take some time, but once it's done we will proceed. And it's about done. Next thing I'm going to do is

[00:57] create the file called handlers.ds. This file will serve as the source of truth for the mock network behavior. In this file I will create a variable called handlers, which equals to an empty array

[01:10] for now, and I will export it for later. Now let's describe what is called a request handler. Request handler is a function responsible for intercepting requests and handling their responses. In MSW you can create request handlers by importing namespaces like HTTP or grepql from MSW.

[01:30] So here I will create an HTTP handler, which means this handler is for HTTP requests, and as the method it actually accepts the methods of this HTTP request. But for now I will call a special all method, which will capture all HTTP requests regardless of their method. The first

[01:46] argument and the second argument. Let's explore those. So the first argument is the path. Basically the path to your resource or maybe a regular expression or a special token. I will use a wild card token, which means match any requests with any path. And the second argument is the resolver

[02:02] function. This is the function responsible for handling this intercepted request. And you can handle requests in different ways. You can return a mock response, you can just observe this request, maybe fire a side effect, or you can perform the request as is and patch in the original response

[02:18] with mock data. Anything you want. But for now let's just grab a reference to the request object. This is the intercepted request, the Fetch API request instance, and just console.log the requests method and request URL. So this is a very basic request handler. We describe what requests to

[02:37] intercept and how to handle them. So for now we will just print any outgoing requests in test in the console. Now what's missing is to actually enable the request interception. For that I will create a setup file, vtest setup.ts. I will then hook this file in the VTEST config by providing a

[02:57] setup files option and I will link it to vtest setup.ts. This way VTEST knows that it needs to run the setup file before the test run starts. In the setup file I need to enable MSW. To do that I

[03:12] will import a function called setup server from msw slash node because here we're using MSW in a Node.js process. Your VTEST tests are still a Node.js process. And I will create a variable called server that equals to setup server call. This is going to do, it will configure the server

[03:29] object that will be our API to control the request interception, to stop it, to modify it, to start it and so forth. Now the setup server function can accept the list of handlers. So let's import the handlers that we defined before. Handlers from handlers.js and I will spread this handlers array

[03:47] as the arguments to the setup server call. Now even though the server object is configured the API mocking is not active yet. For that I will add a before all hook where I will call server dot listen. This will actually start intercepting the requests and run them through all the request

[04:05] handlers that we have to see if there are any matching and to see how they handle that request. To make my experience a little better I will provide an on unhandled request option to this listen call and it will equal to error. This means that whenever MSW encounters a request during a

[04:20] test run that was not present in your handlers, it will print a nice error message for you to let you know. Next I will add an after each hook and here I will call server dot reset handlers. Similar to how we were setting console spies for example between the tests so they don't leak

[04:38] between the tests and don't affect unrelated tests, I will reset any handlers that I may introduce in individual tests. We're going to explore that a little later. And finally I will add the after all hook where I want to clean up completely and stop the request interception by calling server dot

[04:55] close. And this concludes the test setup you need to have to integrate MSW in a vTest test suite.

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.

Learn to mock functions, time, globals, network, and modules. Practice real-world scenarios using Vitest to write effective and maintainable tests.

Mocking Techniques in 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.

Mocking Techniques in Vitest

Mocking Techniques in Vitest

Transcript

Set up MSW

Transcript