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

[00:00] So the first thing to understand is that this new assertion rejects.toThrow uses a syntax called chaining. In simplified form it looks something like this. So it's an object that returns another object and so forth until we arrive at the method we want to call. I will

[00:15] implement this new assertion starting from the type level. So in the setup.ts file we have the assertions interface that represents everything that our expect function returns. So in this interface I will add a new key called rejects that will return an object and that object has

[00:31] a property toThrow which is a method that accepts the expected argument. This is the error that we expect our promise to reject with and in turn has a promise as a return value. And this is important because just as promises may take time to resolve they can also take time to reject and it's

[00:48] important to wrap this in a promise so we can properly evade that rejection when it's happening. So now when these types are defined I can see that TypeScript is kindly screaming at me that I need to implement them as well. Let's do that. We will add the rejects property here with a toThrow method and let's implement it right here. So the first thing that we need to do is to

[01:08] keep in mind that the actual argument that we pass to the expect function is unknown. We don't know what that value is going to be but in the context of rejects.toThrow it must be a promise. So the first thing I will do I will add the check that the actual argument is a promise and if it's not

[01:24] I will throw an error that we expect it to receive a promise because we cannot call this assertion on anything else but a promise. Once I do this I will return another promise and in this instance we will return the catch promise. This means that we are not interested when the actual value

[01:42] resolves but instead we need a promise when it will reject and here I will compare this error message with which the promise rejected with the expected error coming from the toThrow method and if they are not the same I can just say expected error message to be something but got

[01:59] something else. So in this case this is enough for it to work but there is one catch. Since our assertion is focusing on rejections, so we expect rejections to happen, when the actual promise resolves in this implementation it will still pass but that is not correct and what we need to do is

[02:17] to add a then handler that will throw an error stating that we are not expecting this promise to resolve. Yes, expected promise to reject. So here we have this implementation that checks the actual argument to be a promise and then returns us another promise that waits for this actual

[02:35] promise to reject and then compares the rejection with the error message that we want. Now let's use it in the test. So we have the snippet prepared and now we have this chaining annotated and implemented correctly and we just need to provide an error. I'm going to grab it from the

[02:50] source code as it is and pass it right here. So with this let's try running the tests and you can see that we have this test for throwing a rejection when we don't provide the response passing. So even though this is the asynchronicity that we cannot await directly

[03:07] because we expect it to fail, we still need to await it. In this case we await the promise returned by the to throw assertion. So then we can always reliably assert on the error that this promise rejected with.

Error Assertions for Rejected Promises

[00:00] To make a greetByResponse function more robust, we're adding a check here for the cases when the response is not provided, we will throw an error letting whoever is using this function know that they're forgetting to pass in the response. Now let's write an automated test just for this scenario.

[00:15] The thing is, if we just await the greetByResponse function, that won't do us any good, because in this circumstance, the promise is expected to reject. The task in this exercise will be to modify the existing expect function so it can accept

[00:30] a promise that's still pending, and then give you back this nice chaining of rejects.toThrow to help you assert on the exact error message used to reject that promise. That sounds like a fun exercise, isn't it?

Discord

Email

GitHub

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

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

Handle Test Side Effects

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'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.

Get access to Testing Fundamentals

And continue watching this video