If our request fails, the error message is really useless. The server sends us back a much more useful error message, but by default Jest wont display that error properly and we can’t identify the line of code that made the failing request. Let’s use a custom axios interceptor which will improve those error messages considerably by displaying the response that the server returned.

Test Node.js Backends

Improve Error Messages with an axios Interceptor

Instructor: [00:01] One of the most important things that you need to do when you're writing tests is make sure that when there's a failure, it's as easy as possible to debug that failure, find out where that problem is, and fix that problem. I'm going to manufacture a little problem here by making a little typo.

#### auth-controller.js

```javascript
const existingUser = await usersDB.readByUsername(username);
if (!existingUser) {
  return res.status(400).json({ message: `username taken` });
}
```

[00:17] That's going to fail our test because we have this registration endpoint that's handling registration. It's checking if there's an `existingUser`. Now, we've said if there's not already an `existingUser`, we're going to respond with a `400` and this `message`, which is going to result in a really bad error message.

![Typo](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1575572534/transcript-images/29_scikit-learn-improve-error-messages-with-an-axios-interceptor-typo.jpg)

[00:33] All we're getting here is `Request failed with status code of 400`. It would be really nice if we could at least get the error `message` that we're getting back in the response. Let's take a look at how we can make that happen. If I go to my test here, the request that's failing is right here. I only know that because I'm the one who's recording this video for you.

[00:51] What I'm going to do is we're going to add a `.catch` here because we know that this request is going to fail. This is going to be our `result`. I'm going to `console.log` the `result.response.data`.

#### auth.exercise.js

```javascript
test("auth flow", async () => {
  const { username, password } = generate.loginForm();

  // register
  const rResult = await axios
    .post("http://localhost:8000/api/auth/register", {
      username,
      password
    })
    .catch(result => {
      console.log(result.response.data);
    });
});
```

[01:03] If I save that, look at our console `message` method here, we're going to see the `result` actually has the data. It's just not displaying it properly and then the `error` we're getting her is actually just on this next line and that's because I convert the promise to a resolve promise.

![Log Message](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1575572533/transcript-images/29_scikit-learn-improve-error-messages-with-an-axios-interceptor-log-message.jpg)

[01:17] Let's just `throw` the result back so it just continues in a failed state. That's going to get us back to our original `failed with status code 40`0 totally useless message. I just really want to have this error message in here.

```javascript
test("auth flow", async () => {
  const { username, password } = generate.loginForm();

  // register
  const rResult = await axios
    .post("http://localhost:8000/api/auth/register", {
      username,
      password
    })
    .catch(result => {
      console.log(result.response.data);
      throw result;
    });
});
```

[01:32] Instead of throwing the `result` we can actually `throw` our own `message`. Say `throw new Error` and that'll be `result.response.status` and then `result.response.data`. This is an object and we're throwing an error which requires a string. We're going to do `JSON.stringify` that data.

```javascript
test("auth flow", async () => {
  const { username, password } = generate.loginForm();

  // register
  const rResult = await axios
    .post("http://localhost:8000/api/auth/register", {
      username,
      password
    })
    .catch(result => {
      console.log(result.response.data);
      throw new Error(
        `${result.response.status}: ${JSON.stringify(result.response.data)}`
      );
    });
});
```

[01:53] Now take a look at this error message. We're getting a `400` status code. Here's the `message` that we're getting. It's so much easier for us to figure out what the problem is because we have access to the data right in our error `message`.

![Error Message](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1575572534/transcript-images/29_scikit-learn-improve-error-messages-with-an-axios-interceptor-error-with-message.jpg)

[02:05] Also, the code frame is a lot closer to where this problem is actually happening. We can click on that. It'll take us right where it is and we know, "Oh, this is auth register request that's failing not the auth login," for example.

[02:18] Whereas before if we'd comment this back out, save that, then they're actually is no code frame because none of this code is inside of our own test file. We have no idea which one of these requests is failing.

![Code Frame](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1575572533/transcript-images/29_scikit-learn-improve-error-messages-with-an-axios-interceptor-code-frame.jpg)

[02:28] Having something like this makes things a lot better, but it's still not awesome and great. I certainly don't want to add this to every single one of the requests that I'm making. That would just be a total nightmare. You want to me to do that? I don't want to do that. No, we're not going to do that. Don't worry.

[02:45] Let's just get rid of all this stuff. What we're going to use instead, is I build this tiny little abstraction using the Axios interceptor's API. We're going to say `api.interceptors.response.use`.

[02:58] This is going to be our success response. If we wanted to name this to be `success` or `onSuccess`, this is going to be a `response`.

When a response is successful, then we'll just `return` the `response`. For now, we'll just leave that as is.

```javascript
  const baseURL = `http://localhost:8000/api`
  api = axios.create({baseURL})
  api.interceptors.response.use(function onSuccess{
    return response
  })
```

[03:11] Then, here is our error. `onError`, this is going to be a `response` for the error, and then we're going to `throw` that `response`.

```javascript
const baseURL = `http://localhost:8000/api`;
api = axios.create({ baseURL });
api.interceptors.response.use(
  function onSuccess(response) {
    return response;
  },
  function onError(response) {
    throw response;
  }
);
```

This is the default `onSuccess` and `onError` handler for the Axios interceptors. I just want to change this one a little bit, so that it's doing what we were doing before.

[03:30] Let me just paste that stuff in. We'll get rid of this, get rid of that. Here, we'll call that `response`. I guess it's technically `result`. That makes a little bit more sense here, so say `result`.

```javascript
const baseURL = `http://localhost:8000/api`;
api = axios.create({ baseURL });
api.interceptors.response.use(
  function onSuccess(response) {
    return response;
  },
  function onError(result) {
    throw new Error(
      `${result.response.status}: ${JSON.stringify(result.response.data)}`
    );
  }
);
```

[03:43] We are getting this nice error message somewhere in the right stack trace, but the code frame here is showing up on this line, which is a generic line. It's not super helpful. I'd like the code frame to show up right here, so that my error message can show me exactly the part of the code that's making the request it's failing.

![Code Frame Issue](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1575572533/transcript-images/29_scikit-learn-improve-error-messages-with-an-axios-interceptor-code-frame-wrong.jpg)

[03:59] That is what this little abstraction does in our `utils / async`. Under `test / utils / async`, we've got this `handleRequestFailure` which is going to manually edit the `error.stack` trace so that it gets rid of itself, and the resulting code frame will be in the right spot. We're going to use that instead.

#### async.js

```javascript
const getData = res => res.data;
const handleRequestFailure = ({ response: { status, data } }) => {
  const error = new Error(`${status}: ${JSON.stringify(data)}`);
  // remove parts of the stack trace so the error message (codeframe) shows up
  // at the code where the actual problem is.
  error.stack = error.stack
    .split("\n")
    .filter(
      line =>
        !line.includes("at handleRequestFailure") &&
        !line.includes("at processTicksAndRejections")
    )
    .join("\n");
  error.status = status;
  error.data = data;
  return Promise.reject(error);
};

const resolve = e => e;

export { getData, handleRequestFailure, resolve };
```

[04:18] We'll come up here, and `import` `handleRequestFailure` `from utils async`. With `handleRequestFailure`, we're going to just stick that in there, instead of our own custom `onError` handler. Check this out.

#### auth.exercise.js

```javascript
import { handleRequestFailure } from "utils/async";

const baseURL = `http://localhost:8000/api`;
api = axios.create({ baseURL });
api.interceptors.response.use(function onSuccess(response) {
  return response;
}, handleRequestFailure);
```

[04:32] Now, we have a nice code frame. Let me just expand that a little bit. It's showing us exactly where this error is happening in our test code. We're getting this nice error output, so we know exactly which request is failing, and we know the error message that that request is getting back which is great.

![Good code frame](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1575569020/transcript-images/29_scikit-learn-improve-error-messages-with-an-axios-interceptor-good-code-frame.jpg)

[04:47] We can also use this interceptor's API to simplify some of these a little bit because, on every single one of these, we're getting the `data` property. It'd be cool if we just automatically get the `data`, rather than this result or this response object.

[05:00] What I'm going to is, we'll just `return response.data`. Now, I can update this to be `rData` and `rData`. Then, this one's going to be `lData`, this will be `lData`, this will be `rData`, and `lData`, and `lData`, and this is going to be `mData` and `mData`. With that, we're still getting our failing test, but we're able to have the data, which is what we care about.

```javascript
test("auth flow", async () => {
  const { username, password } = generate.loginForm();

  // register
  const rData = await api.post("auth/register", { username, password });
  expect(rData.user).toEqual({
    token: expect.any(String),
    id: expect.any(String),
    username
  });

  // login
  const lData = await api.post("auth/login", { username, password });
  expect(lData.user).toEqual(rData.user);

  // authenticated request
  const mData = await api.get("auth/me", {
    headers: {
      Authorization: `Bearer ${lData.user.token}`
    }
  });
  expect(mData.user).toEqual(lData.user);
});
```

[05:32] Our async utilities has a method that we can use for that as well. Let's pluck that out of there and plug it right into our success interceptor.

```javascript
import { getData, handleRequestFailure } from "utils/async";
api.interceptors.response.use(getData, handleRequestFailure);
```

Now, a`pi.interceptors.response`. On responses, I want to intercept those responses and manipulate them in some way.

[05:52] For successful responses, we're going to pass it through `getData`, which would give us the `data` rather than the `response` object. For failures, we're going to get a nicer error message, as we can see right in here. Let's go ahead and we'll fix this error right here. We'll save that, and boom! Our test is passing.

![Test Passing](https://res.cloudinary.com/dg3gyk0gu/image/upload/v1575568730/transcript-images/29_scikit-learn-improve-error-messages-with-an-axios-interceptor-passing.jpg)

[06:11] Let's go and review this now. We didn't change a whole lot in here, other than changing from `rResult` and `lResult` to `rData` and `lData`. We don't have to deal with that result object anymore. Other than that, everything in here is changed. We added the `api.interceptors.response.use` so that we could get that data benefit for successes.

[06:30] In the event of an error, we get a much cleaner error message, so that it's easier for us to debug that error message, identify where the problem is, and fix it, which is really paramount when you're writing tests.

[06:42] You should really be thinking about how hard would it be for somebody to fix a problem, if a problem were to arise in these tests. That's why we write this little helper utility in our async module to handle request failures.


Backends hold so much of our application's business logic that is often used to support multiple clients (web, mobile, and other native platforms). This logic is critical to get right and deploying a breaking change to this can be devastating to your company's goals (not to mention the bottom-line). Increasing your "deployment confidence" is crucial and automated testing is the best way to do that.

As Node.js continues to grow in usage around the world, learning how to test this mission-critical code in a way that increases developer velocity as well as confidence becomes increasingly important. In this workshop we use an Express.js example and focus on the patterns and practices that you need to learn so you can apply what you learn to test your code written in any Node.js web framework.

You'll learn:

Intro to Test Node.js Backends

Of all things you can test, the easiest thing you can test is a pure function because they require no setup or teardown. In this exercise, we’ll explore testing a pure function called isPasswordAllowed.

Test Pure Functions Overview

Let’s write the basic tests for our simple isPasswordAllowed function to ensure that both valid and invalid passwords receive the correct return value.

Write Unit Tests for a Simple Pure Function

One of the most crucial things you can do when writing tests is ensuring that the error message explains the problem as clearly as possible so it can be addressed quickly. Let’s improve our test by generating test titles so error messages are more descriptive.

Improve Error Messages by Generating Test Titles

Jest has a test-generation feature built-in called test.each which is great, but I don’t particularly like it’s API. Instead, we’re going to use an open source project called jest-in-case which gives us a really nice API for generated tests and improved error messages. Let’s try that library out for our isPasswordAllowed tests here.

Use jest-in-case to Reduce Duplication and Improve Test Titles

Even with jest-in-case there can be a little boilerplate and you can easily side-step that by creating a simple function that allows you to write test cases that are more suited for your use case. Let’s give that a try!

Create a Casify Function to Generate Cases for jest-in-case

There are various types of middleware and for many of them you write tests for them in the same way, so let’s get a look at one of these and try our hand at writing some tests for it.

Test Node Middleware Overview

We have an error middleware in our app for handling uncaught errors throughout our application. Let’s write our first test case for handling an UnauthorizedError which our authentication abstraction throws when someone attempts to access data they shouldn’t.

Write a Unit Test for Handling an UnauthorizedError

Our next test will be really similar to the first. This time we want to handle the case where a response has already been sent which you know if the res.headersSent property is set. So we’ll add that property to our fake response object and verify the middleware behaves correctly.

Write a Unit Test for Handling headersSent in an Error Middleware

Our final case is the fallback scenario where we don’t know exactly why things are failing. In this situation we’ll just give all the information that we can and hopefully the developers can figure out what that is. Let’s write a test case for that situation.

Write a Unit Test for Status 500 Error Middleware Fallback

We’ve got a little bit of duplication between these tests and in a more complex middleware we’ll have a lot of duplication. The duplication itself isn’t necessarily problematic. The problem comes in the form of readability of our tests. When there’s a great amount of duplication, it makes it harder to identify the parts of the test that distinguishes it from other tests. In this lesson we’ll apply the object factory pattern to reduce duplication and make it easier to maintain our tests.

Improve Test Maintainability using the Test Object Factory Pattern

We’re going to need the same utilities for our object factories in several places in our tests, so let’s use some pre-built utilities instead of the ones we wrote for this file.

Use a Test Object Factory utils/generate

Controllers are a collection of middleware that applies business logic specific to your domain. Typically these are tested like any other middleware, but often they require mocking the database for unit tests.

Test Node Controllers Overview

Let’s write our first controller middleware unit test by mocking out a database call and verifying that the database is interacted with correctly and the response is sent correctly.

Write a Unit Test for a Controller by Mocking the Database

Let’s add a test for an edge case that responds with an error message. In this lesson we’ll talk about the value of using the toMatchInlineSnapshot assertion for error messages.

Simplify Assertions on Error Messages with toMatchInlineSnapshot

Not all controller middleware send responses. In this unit test, we’ll verify that a controller’s middleware interacts with the request, response, next function, and database correctly.

Unit Test Business Logic of a Controller’s Middleware

Sometimes people try to access data that’s not there and it would be great if our server doesn’t fall over when they do, so we have some code to handle that case. Let’s get that tested and use toMatchInlineSnapshot for asserting on the error message.

Test Controller 404 Edge Case where Resource is Not Found

If the user tries to access a resource they shouldn’t have access to, we need to make sure they can’t get that resource, and we’ll want a test to make sure that functionality doesn’t break because this is a data security concern. In this one we handle dynamic data in a snapshot by making a consistent ID for the user and list item.

Test Controller Unauthorized Case

We have another controller function we want to test that will retrieve all of the user’s list items. For this one we’ll need to mock out a few new APIs and build multiple books and list items. Then we’ll have to do a few things to ensure that the APIs were called correctly.

Test getListItems for Getting Multiple Mock Objects

We want to test the createListItem controller function so we can ensure that users can create new list items. In this one we need to mock out several database requests. We also see how great Jest error output is which helps us identify a few mistakes that we made really easily.

Test the Happy Path of a Creation Flow

Even though your edge cases don’t run as often as your happy path cases, they are important to test to make sure you handle those correctly. In this one we’ll verify that if a user attempts to create a new list item for a book even though they already have a list item for that book.

Testing an Error Case for createListItem

For this one, we’ll need to have an existing listItem and we’ll create some new notes for it. Then we’ll have the original list item and the updated list item and ensure that our API is being called with the right version of the list item.

Testing the Happy Path for updateListItem

This one’s a bit unique because it’s pretty simple. All we need to do here is verify that the remove method of our was called properly, but we don’t need to bother mocking out what it returns because our code doesn’t use that return value. We also want to verify that the res.json was called properly, so we’ll do that as well.

Testing Resource Deletion

Let’s start doing some server integration tests. We’ll get our server started and database going so we can hit the endpoints in the same way clients will be using our endpoints. Let’s explore how our app is started so we can start it in our test environment and I’ll show you around the codebase so you can navigate around while you test things out.

Test Authentication API Routes Overview

Let’s get our test ready to roll by getting our API server and database started and in a clean state. Because our tests and server both run in node, we can do this all using the utilities that Jest exposes for us like beforeAll and afterAll. Then we’ll get a test started and fire a request to the API to make sure we can communicate with the server.

Start a Node Server and Fire a Request to an HTTP API Endpoint

When you’re interacting with the API response of a server, some of the data you receive is information that you cannot assert on directly. In this lesson we’ll talk about how to use Jest’s asymmetric matchers to assert on the type of data your server is sending.

Make Assertions on HTTP API Responses for Registration

Let’s make another request in this same test to the login endpoint with the same post data as we used for registration. Then we can verify that the information we retrieved from the registration request is the same as the information we retrieved from the login request.

Test the Login Endpoint for a Node Server

Our server has an API for authenticated clients to request information for the currently logged in user. Let’s make an authenticated request using the user token we retrieved from the login request to get confidence that the token generated will get the data for the user.

Test the User’s Resource Endpoint

We’ve got a bit of duplication in our test for each request and it’d be nice to remove that, so we’ll create a pre-configured axios client to reduce that duplication.

Create a Pre-configured axios Client for the baseURL

If you want to run your tests in parallel and each of your tests starts up the server on its own, then you could run into a problem where two servers try to bind to the same port. To avoid this, we can use the JEST_WORKER_ID environment variable so we can ensure that the port our server starts on is unique. Let’s try that out.

Ensure a Unique Server Port

Let’s test the case where we try to register two users of the same username. We’ll first register a user, and then we’ll attempt to register a second user with the same username and assert on the error message. We’ll use toMatchInlineSnapshot on the error that’s returned and Jest will serialize that like a champ.

Use Snapshots to Assert on Server Error Responses

Often in integration tests you’ll have situations where you are over testing. Sometimes that’s acceptable, but you can speed up your tests by getting your application into a testable state a little quicker. In this lesson we’ll skip hitting the API for our setup and instead interact directly with the database.

Interact Directly with the Database

Integration tests are typically best for common cases and you can cover other cases using lower level tests, but I thought it’d be interesting to show you how to cover a few other edge cases as well in this lesson.

Test all the Edge Cases

Things change a little bit when we want to hit an endpoint that requires the user to be authenticated. For this exercise you’ll need to use an authenticated test with a test user that’s already in the database. Then you can use that test user for each of the operations you do on the list item resource (Create, React, Update, Delete).

Test CRUD API Routes Overview

Let’s get a test user and authenticated axios client, and then we’ll need to generate a book and insert that into the database directly so we can create a list item for our test user for that book. Then we can verify that the response data is correct.

Write an Integration Test for a Resource Create Endpoint

Now that we’ve created a list item, let’s try to read that list item. This will give us confidence that the list item we created was actually saved to the database and can now be retrieved.

Write an Integration Test for a Resource Read Endpoint

For the update, we’ll need to create new notes for our list item and send those updates to the updates endpoint. Then we can verify that the response we get back is the same as the original list item except with the updated notes.

Integration Test a Resource Update Endpoint

For our delete endpoint, we don’t need to do too much beyond hitting the endpoint, but it could be problematic if we just hit the endpoint and verify the response. In this lesson we’ll find out why that is and how we can use our test to make sure that the item was actually deleted from the database.

Integration Test a Resource Delete Endpoint

Typically, it’s nicer to use toMatchInlineSnapshot for error messages, but sometimes the contents of the error message are generated. But I’ve got a little trick for solving this problem that you’ll probably find useful.

Improve Error Messages with an axios Interceptor

Transcript

Improve Error Messages with an axios Interceptor