Mock responses

[00:00] The first thing I will do is remove this HTTP.ALL handler. Once it's gone, I need to create a more targeted handler for the request that our tested code makes. So let's take a look at that request. It's a POST request to this particular URL. I will copy this URL and go back to the handlers.

[00:17] So I will create an HTTP.POST call which targets all POST requests, and I will provide this URL as the path argument. Then I will create a resolver function, and here I can handle this intercepted request in many different ways. But right now I want to respond to it with a mock response.

[00:36] So let's first construct that response by calling response.json. This is a static method on the global response class, and this creates a JSON response, and it expects buddy here. So in our getAuthToken function, the successful scenario expects the buddy to have a token property. So I will provide an object

[00:55] here with token that equals abc-123. And now that I have this response created, all I have to do is return it. And this will let MSW know that when it intercepts this matching request, it should use this response to respond to it. Now with this in place, I will go to my test file

[01:15] and finally create an assertion for this getAuthToken function. So I will expect that calling getAuthToken with these credentials will return the token object where the information will be as I defined in my mock. Not that I'm using this await, expect, and dot

[01:32] resolves syntax. I do this because if this promise rejects, Vetus will print a more nicer error message when that happens. So I'll be able to figure out why this promise rejects in a faster way. So here I will run the test with npm

[01:49] test to verify that they are passing. They are passing. What happens here is that when our getAuthToken function performs this post request right here, MSW intercepts it, finds this matching handler matching by method and also the request URL.

[02:05] And since we're returning a particular response instance, the mock response instance, it will use this JSON response as the response that we receive here. And then of course because it's a successful response, it will read its body and return this

[02:20] particular token that we're able to assert on in our automated tests.

[00:00] What we have here is an extremely permissive request handler. It matches all HTTP requests our app makes. Now, this can be handy in certain situations, like when you want to observe the outgoing traffic, for example. But when mocking API is in test, it's rare that you want to handle a bunch of requests in the same way. In this exercise,

[00:19] your task will be to write a more targeted request handler. You will remove this HTTP all handler and instead create a new handler precisely for this request that we're making in the getAuthToken function. You will match this request by its method and also the request URL. And your next assignment will be to respond

[00:37] to that intercepted request with a mock response. Now, this function can handle a bunch of different response scenarios. But for this exercise, your task will be to reproduce a successful response, which is a JSON response with a token property in its body. And once you do that, head to the test case for this function

[00:55] and complete it by creating an assertion to make sure that the getAuthToken function returns the correct token. Give it your best shot and see you in the solution to this exercise.

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

Mock responses

Transcript