Learn how to handle side effects introduced by the Date constructor in your JavaScript tests.

Create global hooks for setup and tear-down, mock the Date constructor using a Proxy, and then restore it after your tests are ran.

Implement Hooks for Test Setup & Cleanup

[00:00] Because a grid function introduces a side effect by constructing a new date, it needs a proper setup to run. The setup phase is the most important part of any test, because it prepares the environment for the tested code to run.

[00:12] For example, by handling side effects and dependencies introduced by the code, making those variable and unpredictable parts fixed and given. Because the setup phase is tightly coupled to how tests are run, you will often find testing frameworks giving you the APIs to implement the setup,

[00:28] such as functions like before_all and after_all that are called hooks. I will start by adding those functions, those hooks, to our testing framework. Much like expect and test, those functions will be available globally, so I will head to setup.ts and make them global. First, I will declare them on a type level.

[00:46] So, before_all function will accept a callback, which is another function, and then return nothing. And similar to this, we will have an after_all function that does quite the same. Remember that this is just the type part of the globals, and now we have to provide the actual implementation for before_all and after_all. So, let's do that.

[01:05] We're going to head here and assign a new key to the global list object called before_all, which is a function that accepts the callback, the one we just described. And inside this function, we will just call this callback immediately. So, this stands for executing the callback as soon as the before_all function, this hook, is called in our test. Let's do the after_all function now.

[01:25] In the same way, we will assign it to the global object, but here we cannot really call callback straight away. It would be awesome to call it when the tests are done. To listen to this, we will rely on the before_exit event on the process, which is a global object in Node.js,

[01:39] and this event will emit whenever the process of the test is about to exit, which indicates that the tests are done. And we will call the callback then. So, the before_all hook will be responsible for introducing any logic to handle side effects,

[01:53] and after_all hook will run when the tests are done to clean up whatever logic we introduced in the before_all hook. With these hooks in place, let's head to our test and now mock the date to make it more predictable. So, first I will store the original implementation of the date from the global list of date constructor on the original date object.

[02:12] Then I will add the before_all hook, and here I will mock this global date constructor by introducing a proxy. Proxy is a global API in JavaScript that will allow me to spy on this class and know when it's being constructed, so whenever any tested code calls new date.

[02:31] And instead of constructing it for real, we will return a fixed date using the original date constructor that will point to the 1st of January 2024, which happened to be Monday. Now, with this in place, we can mock and control the date whenever it's called, so it's no longer unpredictable. But we need to clean up ourselves so this proxy doesn't leak to unrelated tests.

[02:50] To do that, we have the after_all hook. So, inside this hook, we are going to reassign the global_date variable to the original date that we stored before, introducing any kind of mocking. Now, let's try running these tests.

[03:07] So, both tests are now passing reliably, even though I'm recording on Friday. The greeting for the John will still mention Monday, because we introduced the mock for the date constructor that will always return Monday. And now, our test for the greet function passes the golden rule of assertion,

[03:24] which states that the test should only fail when the intention behind the tested code is not met. This means that even if the actual greeting message includes "Happy Friday", that's still a perfectly functional code. It's just an indication that our testing setup is not efficient and doesn't handle a side effect in this case.

[03:42] I encourage you to refer to the golden rule of assertions often when writing tests, because it can help you tell apart good tests for bad ones, for example, those that miss the testing setup.

Handle Test Side Effects

[00:00] So we have our code, and we have our tasks, and everything works just nicely. Until one day, Peter, the project manager, comes in and suggests an improvement. How about we add a weekday to the greeting message? So it would say, "Hello John, happy Monday!" That sounds like a fantastic idea, so we jump ahead and implement it. We create a new date, and we convert it to a local string,

[00:19] using the locale of our application to be consistent, and grabbing the weekday in a long format, so it would say "Monday", "Tuesday", and so forth. And then we add it to the message, so now it says, "Hello name, happy weekday!" Because our intention behind this greet function has changed, we need to go to the tests and adjust the expectations here too.

[00:37] In fact, this is the only legitimate reason to do so, because now our greet function does something it didn't do before, includes the weekday. So we adjust the expected string to be "Hello John, happy Monday!" Here's the problem with this test, though. It will only pass on Mondays. But this isn't what we want. We want reliable tests that pass whenever we call them.

[00:56] So in this exercise, your task would be to handle the side effect introduced by the greet function. The side effect in the form of a new date constructor. You will mock that constructor, and make it return a fixed date, no matter when the test is run. And you will do so by introducing a setup phase to our test, to our little testing framework,

[01:14] and add a new helper function called "beforeAll" and "afterAll" to orchestrate this mocking, and also clear up once the tests are done. That sounds like a fun challenge to me and I can't wait to see how you solve it.

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.

In the Testing Fundamentals workshop, you will learn testing principles, framework structure, async handling, and more by building a mini testing-framework!

Testing Fundamentals

Artem Zakharchenko

This workshop covers testing framework structure, asynchronous code, and migrating to Vitest.

Testing Fundamentals Workshop Introduction

Introduction

In this first section, you'll learn by example the core principle of having intentions when testing.

Overview of Testing Principles

Learn how writing an automated test captures your intentions, while manually calling console.log() and viewing the result only really lives in your head.

Learn how you can explicitly define your intentions and automatically test your code without any testing frameworks.

Implement the Automated Greeting Test

Write an Intentional Test

Learn how to create an expect function that provides a readable API for writing tests and refactor existing tests to use it.

Trusting Your Test

Debugging Intent vs. Implementation

You've completed the principles exercise!

Testing Principles Outro

Principles

In this exercise, you will learn about the setup, action, and assertion phases of automated testing and how they applied to testing our simple greet function.

Structure Your Tests

Learn how to write declarative and readable assertions in your TypeScript tests using a custom expect function.

Implement a Declarative API

Imperative vs. Declarative Assertions

In this exercise, you will figure out how to create a test function to isolate and report test results.

Learn how to create a simple testing function in JavaScript to wrap existing tests, provide meaningful test names, and display visual indicators.

Create Test Blocks for Better Organization

Isolating Tests with Test Blocks

In this exercise you'll be figuring out how to separate the test cases into a separate module and make testing functions globally available.

Learn how to gracefully move tests to a separate file, export functions, make test functions global, and run tests using Node.js.

Modular Tests and Global Helpers

Move Tests into Modules

You learned how to write declarative assertions, provide test isolation, put your tests in separate files, and deal with testing setup.

Test Structure Recap

Test Structure

In this exercise, you will expand your testing library to support testing asynchronous code, and then write tests for an asynchronous greet function.

Overview of Testing Async Code

In this problem, you'll need to figure out how to adjust the test function to support asynchronous callbacks.

Learn how to handle asynchronous functions in tests by using the `await` keyword and marking test functions as asynchronous. 

Awaiting Async Tests

Handling Promises in Tests

In this problem, you will need to figure out how to handle a pending promise and then chain .rejects.toThrow on expect.

In this solution, you'll learn how to use the object chaining syntax to extend the `expect` function with a new assertion called `rejects`.

Handling Promise Rejections

Error Assertions for Rejected Promises

In this problem, you'll create a waitFor method that can await state changes to a notification manager.

Learn how to use a waitFor method to retry a callback until it no longer throws an error or until the maximum number of retries is reached.

Reliably Wait for Async Operations

Testing with Async Side Effects

You've learned about asynchronicity that you can and can't control, and testing strategies for dealing with both.

Recap of Testing Asynchronous Code

Testing Asynchronous Code

In this final section, you'll be migrating your tests to Vitest.

Overview of Vitest

Your task is to follow the outlined steps to migrate your project from your custom framework to Vitest.

Congrats! You are now ready to apply everything you've learned today about testing in practice!

Installing, Configuring, and Testing in Vitest

Migrate Tests to Vitest

Outro to the Moving to Vitest section of the Testing Fundamentals workshop.

Vitest Review

Moving to Vitest

After completing this workshop you are now equipped to approach any test. There is a lot more to learn about testing! Be sure to check out the linked materials.

Testing Fundamentals

Testing Fundamentals

Transcript

Handle Test Side Effects

Transcript