Error responses

[00:00] Let's start from refactoring our test setup so we're able to reference the same server object both in the setup and in individual tests. So I will take all the setup server call and its inputs and just move them to a different directory called mocks. In there I will create a module

[00:16] called node.ts and paste them here. Since we also use handlers, let's move them from the root to this newly created mocks directory. That's it. And the last thing remaining is to export this server variable so we're able to reference it whenever we need. In fact let's go to vtest setup

[00:33] and now import this server from mocks mocks slash node.ts and we will leave the rest of this setup vtest setup as it was before. Now let's try running our tests. So if I try running the tests

[00:50] I will see that all these two error scenarios are failing because we're expecting the promise of get auth token to reject but it actually resolves with what looks like a successful response. That's precisely what's happening because all of them receive this successful response from

[01:07] our base handlers. So what we want to do now is to go to individual tests and import the server. I'm going to import the server from the same directory mocks slash node.ts and I will head to this error case scenario and what I would do I would add a runtime request handler by calling

[01:24] server.use. This use method supports a bunch of request handlers that will act as overwrites to your network behavior. So here I will create a matching handler for our post request using this

[01:38] url as a path and in the resolver I'm going to respond by returning a 401 response the one we need to reproduce in order for this particular error to even happen when we call our function. Since we are creating this handler we also need this HTTP namespace I will import it from MSW.

[02:01] Okay in a similar fashion let's create a runtime handler for another scenario where we are testing generic error handling by reproducing 500 responses. With this we can see that both successful happy path scenario and the error scenarios are passing

[02:17] and notice that in the second case although we are testing an invalid input scenario the input itself doesn't matter because verifying its validity is the responsibility of the server. The responsibility of our get of token function is to properly handle a 401 response and that's

[02:35] precisely what we're doing here we're always responding to this request with a 401 response so we're able to reproduce this error scenario in tests. Runtime handlers are extremely powerful because they allow you to provide network overrides on the test level while still

[02:51] respecting the happy path scenarios like this first test which will respect your default handlers.ts array.

[00:00] One of the reasons you want to be in charge of the network is so you're able to reproduce all sorts of network-dependent scenarios. Like here, our getofftoken function has a special handling for 401 responses. Those are the cases when the credentials you provided were invalid,

[00:16] and when that happens it throws this nice error message. So it would be nice for us to return this 401 response so we're able to trigger this particular logic in tests. But if we head to our handlers and just replace the mock response to be an error response, we will be hard-coding it

[00:33] for all the matching requests in tests. And that's not a great behavior. In fact, a much better approach is to keep this handlers array exclusively dedicated to happy path behaviors for situations when your app's supposed to work normally. This way you'd be able to achieve proper

[00:50] network layering. But how do you do that layering? For that, you will create a new special kind of request handler called a runtime request handler. You will use server.use API to do that. But for that API to work, you need access to this server reference. And this is the same server object we

[01:08] have in our test setup right here when we called the setup server function from MSW. But importing this Vita setup in tests is not a good idea. So before you do anything, your task is to follow these instructions and do a bit of refactoring so you're able to reference the same server instance

[01:24] both in the test setup and in individual tests. And once you're able to do that, complete this error response test case by providing a runtime request handler for our post request that will always respond with an error response.

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

Error responses

Transcript