Environment variables

[00:00] To test this logging functionality reliably, I need to gain control over two things. The first one is this environment variable, and the second is the console log function, so I'm able to know how and when it's being called during the test run. So let's do just that. I will let the test set up, calling before all hook, and in that hook, I will introduce the spy

[00:19] over the console log method. I will provide console as the target and log as the method name, and I will mock the implementation for console.log so it doesn't print anything during the test run. Next, I will add an after each hook, and in that hook, first, I will reset all mocks.

[00:36] I will call v.resetAllMocks, and this will clear any records to the console log calls between the tests. And the second thing that I'm gonna do, I will call v.unstubAllEnvironments. This is a cleanup step for the mocks that we will introduce over process.environment later in each individual test.

[00:55] And finally, I have the after all cleanup hook to restore all mocks. So this will revert the console log mock to its original unpatched implementation. There's already one test suite written here for basic emitting and adding listeners, so I'm gonna head to the next one. So in this one, I want to test that the emitter class

[01:14] is actually printing something to the console when the node environment is development. So first, I need to force that environment variable to be development. I will call v.stubEnvironment, and this method accepts the variable name, node environment, and the value, development. So what this is gonna do, it will do basically process environment,

[01:33] node environment, equal development. This is what VTEST is gonna do behind the scenes. So I will do this one, and now I'm able to call my emitter as I normally would, so I'm gonna add a listener. I will introduce a listener as a mock function, and event is gonna be hello. Oh, I already have a listener, nice.

[01:51] And I will expect the console log, which is our mock function, to have been called with adding event listener for hello. Let me look up the right message here, so adding listener for hello event, so for hello event. Here we go. Then I'm gonna emit this hello event

[02:11] with some data using john, john, and my next assertion is gonna be that I'm gonna assert on the message that I'm emitting listeners for the hello event. That includes number of listeners based on the same message that we have right here. So this is a very basic test for the case

[02:32] when we do have to emit those events and have logs associated with them. But what about the production environment? Well, I have another test for production, so I'm gonna call v.stub environment, and here I will use production as the value of the node environment variable. And for the rest of it, the test will be pretty much the same. I'm gonna emit the event.

[02:52] Then I'm gonna make sure that the console log method is not called at all because that's the entire purpose, to emit those login when running production. Then I'm gonna check the same assertion, but this time for the emit of events, so hello with the data of john. And finally, I will also make sure that console log has not been called.

[03:12] Now I will run the tests with npm test to make sure that all of them are passing. So let's recap here. In order to gain control over process.environments, basically environment variables, I'm using v.stub environment method. I provide the environment variable

[03:30] and the value I want it to have. To make sure that these calls don't conflict and persist between tests, I'm adding the after each hook and calling v.unstub all environment. And for the rest of it, I'm combining it with the spy on the console.log method, so I'm able to assert when the emitter class calls console.log.

[00:00] One of the common global dependencies is a dependency on the environment, specifically on the environment variables. Here, let me show you. We've got this emitter class here that looks extremely similar to the emitter from the exercise block on functions. But this emitter

[00:15] is a little special. See, it has logging added. So whenever we add a listener or emit an event, we're going to print the respective console message for the developer to know. But we don't want to have that logging all the time. Especially, we don't want to have it in production. So to

[00:30] account for that, we have this is development utility function. And all it does is basically checks the value of node environment variable, whether it equals to development. Here, you access the global process object in Node.js, its environment variables, and the one that's

[00:45] called node environment. In this exercise, your task is to test this emitter functionality, specifically its logging functionality. And you will be using different environment variable values to do that because there's actually two intentions behind this logging. First one is that you should

[01:00] print messages when running development. But the second one is that you mustn't print any messages if you run in production. And it's going to be tricky because otherwise, you'd be able to provide this environment variable right here on the test command. But since you need to test these two

[01:15] different scenarios, it will be a little different approach. So explore it and see me in a bit.

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

Environment variables

Transcript