Private side effects

[00:00] To mock a module in a test, I will use the v.mock utility. This utility accepts two arguments. The first one is the module name, and the second is a factory function. Module name is the name of the module that you want to mock. This can be a local module or a third-party module, like in my case, it's a workshop slash epicsdk.

[00:22] I can provide an exact string here, or I can use a dynamic input expression. I will choose the latter because this way, these inputs are type-safe. So, if I make a mistake, TypeScript will let me know about it even before the test to run. The second argument is factory function is responsible for producing the experts of this

[00:41] module. So, from the usage, I know that my module here exports a function called query table that I use to query for user. So, I'll add this key here to this experts object. It would be nice if this exported function instead was a mock function, so I'm able to replace its implementation on a test basis and spy on it.

[01:01] So, let's assign it to query table mock, and now let's create this mock function. So, to do that, we know that we need to call v.fn. Notice how we're not adding this v.mock in any setup hooks, like before all. That is because this utility is special. It's hoisted. This means that Vitas will place it and run it as the first thing in this test,

[01:22] no matter what you do. And because of this, there's a bit of a difficulty here. This factory function won't be able to reference the query table mock at all. It will not exist by the moment this function is run. To fix this, I will use v.hoisted utility. This utility accepts a function, and it's

[01:39] a factory function of the things you want to hoist. In other words, kind of put in a box and be able to reference in other hoisted utilities like v.mock. Let's also annotate this mock function that it's a function that returns a promise that resolves to user, because this is what our query table function does.

[01:57] With this in place, since we're using this mocked function query table mock, let's make sure to reset all the calls recorded to it. I will add the after each hook and call v.resetAllMocks. This will reset the spies, but also mock implementations that we'll introduce in these tests. And finally, we can start with particular test cases.

[02:16] In this one, it should return the authorized user. To do this, I will go to my query table mock and mock its resolve value to a particular user object. I will use this mock user as an example. Note that I'm using mock resolve value and not mock return value because query table

[02:33] is an asynchronous function, so this is a shorthand for resolving this function with promise that then resolves to particular data. And finally, I can write an assertion for it by calling authorize with particular ID, for example, abc123, and now I expect it to return the user back as far as I remember.

[02:53] Yes, so that is the very basic happy path scenario. Now, let's also recreate a scenario where our authorized function returns null if there was no user found. So, to emulate the scenario where no user is found, we need to mock the implementation of this function to resolve with null.

[03:11] And I'll also write the expectation around calling authorize with particular user, and it should resolve to be null. And finally, there's an error case. In this case, actually, querying for the user should throw. To do that, I will use a special helper called mock rejected value.

[03:32] So, our query table mock, mock rejected value. Similar to mock resolve value, this is a shorthand for returning a rejected promise from the mock function. And I will use this dummy error as the error that this promise reject with. Now, I can write assertion like this.

[03:49] I expect authorize with particular ID to reject, and to throw an error, I will use the same error that I used here, like this. Let's now verify these tests by running npm test. Okay, it looks like I have a failure scenario here, of course, because the error that I provided isn't the actual error that our authorize function throws.

[04:12] Instead, it throws a more meaningful error for us, the developer. Failed to fetch the user by ID, including the particular ID. So, let's wrap it in this one. By ID, and ID was ABC 1 to 3. Once I fix this assertion, I can see that all the tests are passing all the three scenarios.

[04:31] So, what are we doing here is using v.mock utility to mock a third-party module. By doing that, our test case gains control over that module, in particular, its experts. And bear in mind that because this factory function is the only thing in charge of the module, nothing else except of these experts will ever be exported from that particular module.

[04:51] For example, no side effects will run unless we want them to run. Just keep this in mind to include all the experts you need to test your tested code. And since this helper function is hoisted, we're also hoisting our mock function to be able to control the query table behavior in each individual test.

[05:09] So then, in different scenarios, we're able to call things like mockResolvedValue to resolve this promise, or mockRejectedValue to reject that promise. And this allows us to see how our authorized function behaves when the third-party module, this query table function, differs in implementation.

[00:00] When you use mocks in your tests, you're deviating your tested code from how it would normally behave. Different mocking techniques result in different degree of that deviation, but naturally you would want to keep it to the minimum. You wouldn't want to start testing against the code that's

[00:16] completely different from what you ship in production. And mocking a module is quite a deviating technique. That is why you're almost always better off mocking particular values or behaviors. Even if it seems like those two are abstracted from you, you can still achieve full

[00:32] control without resorting to module mocking. For example, if you're using a third-party request library like React Query or Axios, you don't have to mock that entire dependency to gain control over the network, over the requests that are being sent and responses that are received. Instead,

[00:46] you can draw a test boundary on the network level using tools like MSW. And this way your setup is even agnostic of any particular third-party clients that you're using. That being said, there is at least one legitimate use case to use module mocking. Let's look at it. Here we have an

[01:03] authorize function that's supposed to authorize a user by ID. And to do that, it uses this query table function to query this user in a database. This function itself comes from a third-party package, workshop-slash-epic-sdk. This is a made-up package, but you get the idea. And the thing is

[01:19] about this package is that right in its root, it does a side effect. So on the root scope of this package, some logic is being performed. To make things worse, this logic isn't even exposed to you, the consumer. This is an internal telemetry in this case. So even if you're going to mock this

[01:36] particular query table by spying on it or replacing its implementation, this telemetry logic will still run in tests. And this can result to all sorts of unpredictable behavior. In short, this is the logic that you don't want to run in tests ever. And the only way to eliminate it is to mock this

[01:53] module altogether by replicating its experts, but also removing those root-level side effects. This will be the exact task you have at this exercise. So head to the authorize.test.ts and complete the test suite. Have it running at the end and see you in the solution to this exercise.

Discord

Email

GitHub

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.

Get access to Mocking Techniques in Vitest

And continue watching this video