Forem: Jacques Blom

Mock Service Worker Tutorial Part 2

Jacques Blom — Thu, 31 Dec 2020 07:58:21 +0000

Update: I recently launched a new product called Fudge, which is an AI-powered Shopify page builder & editor. Please check it out if you're interested!

This is Part 2 of my Mock Service Worker Tutorial series. In Part 1 we learned how to install MSW and write some basic tests.

In this article we're going to dive deeper into MSW, looking at:

Testing POST requests.
Testing requests that have route parameters.
Some more testing best practices.
Re-using handlers across tests.
Selectively mocking error states.

To follow along, clone the repo and switch to the part-2 branch:

git clone git@github.com:jacques-blom/taskhero-web.git
cd taskhero-web
git checkout part-2
yarn

Run the tests in watch mode:

yarn test src/App.test.tsx --watch

How to test POST requests with MSW

What we're testing

In our next test, we'll test whether the flow of inserting a task works:

1. Add the handler

Our Taskhero app inserts tasks by POSTing to /tasks. Let's add a new handler to src/mocks/handlers.ts to handle a POST to that endpoint:

// src/mocks/handlers.ts

import {v4} from 'uuid'

// Use rest.post instead of rest.get
rest.post(getApiUrl('/tasks'), (req, res, ctx) => {
    // Make sure we receive a request body as a string
    if (typeof req.body !== 'string') throw new Error('Missing request body')

    // Parse the request body
    const newTask = JSON.parse(req.body)

    // Emulate our real API's behaviour by throwing if we don't receive a label
    if (newTask.label.length === 0) {
        return res(ctx.status(400), ctx.json({message: 'Missing label'}))
    }

    // Emulate our real API's behaviour by responding with the new full task object
    return res(
        ctx.json({
            id: v4(),
            label: newTask.label,
            completed: false,
        }),
    )
}),

In our handler we're emulating how our real API would respond in different scenarios:

We're throwing if we don't receive a body.
We're throwing if the user doesn't provide a label.
We're responding with the new task object if the task was inserted successfully.

💡 We can make our handlers as realistic as possible by responding the same way our real API would in different scenarios.

2. Write the test

Now let's test whether a task is inserted successfully. Before we start, let's extract our logic that waits for loading to complete, to make things easier:

// src/App.test.tsx

const waitForLoading = () => {
    return waitForElementToBeRemoved(() =>
        screen.getByRole("alert", { name: "loading" })
    )
}

💡 If you want to know why and how I am using getByRole, check out my post: Don't use getByTestId.

Let's add our test:

// src/App.test.tsx

it("inserts a new task", async () => {
    render(<App />, { wrapper: GlobalWrapper })
    await waitForLoading()

    const insertInput = screen.getByRole("textbox", { name: /insert/i })

    // Type a task and press enter
    userEvent.type(insertInput, "New task")
    fireEvent.keyUp(insertInput, { keyCode: 13 })

    // Test the loading state
    expect(insertInput).toBeDisabled()

    // Test the success state
    await waitFor(() => expect(insertInput).not.toBeDisabled())
    expect(insertInput).toHaveValue("")

    // Test whether the task is displaying on the page
    expect(screen.getByTestId(/task-/)).toHaveTextContent("New task")
})

In the above test we're testing the whole flow of inserting a task.

Testing best practice: Write fewer, longer tests

This is a practice I've recently started using more. Instead of breaking up each assertion into its own test, combine all the assertions for a given flow into one test.

This means you don't have to set up the environment for each assertion, so:

You have less code in your tests.
They're quicker to write.
They're quicker to run.

I got this idea from Kent C. Dodds's article: Write fewer, longer tests
.

My feeling on how to split up tests is to write a test for a given user flow or state. So for this flow we'll write one test for successfully inserting a task, and another for whether the error state is handled.

3. Testing the failure case

Now we can write a test for the failure case, which is when a user tries to insert a task without a label. This will also cover testing any other error from the API.

// src/App.test.tsx

it("displays an error message if the API fails", async () => {
    render(<App />, { wrapper: GlobalWrapper })
    await waitForLoading()

    const insertInput = screen.getByRole("textbox", { name: /insert/i })

    // Just press enter without typing a label
    fireEvent.keyUp(insertInput, { keyCode: 13 })

    // Wait for loading to complete
    await waitFor(() => expect(insertInput).not.toBeDisabled())

    // Expect an error alert to display
    expect(screen.getByRole("alert").textContent).toMatchInlineSnapshot()
})

💡 When testing a UI interacting with an API, always test how the UI reacts to all possible API responses, including errors. Even if your API never throws, something else like a network error could occur.

Testing best practice: Expecting certain text content, and using snapshots to help you

In our above example, to test that the error being displayed is actually the error from the API, we're expecting the error to display.

If we just tested for the presence of an alert we wouldn't know whether we were displaying the correct error.

To make life a bit easier, we use toMatchInlineSnapshot, which we start by calling without passing in a string (.toMatchInlineSnapshot()). Then, when we run the test for the first time Jest will automatically change it to .toMatchInlineSnapshot('"Missing label"').

Then, if our message ever changes, Jest will ask us whether or not we want to update the snapshot. Try to change the error message in src/mocks/handlers.ts to see for yourself!

How to test requests that have route parameters with MSW

What we're testing

In our next test, we'll test whether the flow of checking a task, calling the API, and then finally marking it as checked in the UI works:

When a task is marked complete, the app makes a POST request to the /task/1 endpoint, where 1 is the ID of the task.

1. Add the handlers

// src/mocks/handlers.ts

rest.post(getApiUrl('/task/:id'), (req, res, ctx) => {
    // Make sure we receive a request body as a string
    if (typeof req.body !== 'string') throw new Error('Missing request body')

    // Parse the request body
    const newTask = JSON.parse(req.body)

    // Get the task ID from the route parameter
    const taskId = req.params.id

    // Emulate our real API's behavior by responding with the updated task object
    return res(
        ctx.json({
            id: taskId,
            label: 'Example',
            completed: newTask.completed,
        }),
    )
}),

💡 You can use the :paramname syntax to specify that this endpoint will take in a parameter. Just like Express.js routes, this parameter will be accessible from the req.params object.

For this test we're also going to have to display a task on the page. To do this, let's create a handler in src/mocks/handlers.ts:

// src/mocks/handlers.ts

export const singleTask = rest.get(getApiUrl("/tasks"), (req, res, ctx) => {
    return res(
        ctx.json([
            {
                id: v4(),
                label: "Example",
                completed: false,
            },
        ])
    )
})

You'll notice we're exporting it from the file, rather than passing it to the handlers array. That's because passing it to the handlers array would override our existing mock for /tasks. We could have just included this in the test itself, but I know we're going to reuse it. And adding it here makes it easy to reuse.

💡 You can make handlers easily reusable by exporting them from a handlers file and importing them in your individual tests.

2. Write the test

// src/App.test.tsx

// Import our singleTask handler
import { singleTask } from "./mocks/handlers"

it("toggles the task completed state", async () => {
    // Mock a single task on the page
    server.use(singleTask)

    render(<App />, { wrapper: GlobalWrapper })
    await waitForLoading()

    // Click the checkbox
    userEvent.click(screen.getByRole("checkbox", { name: /mark as completed/ }))

    // Expect it to be disabled while loading
    expect(screen.getByRole("checkbox")).toBeDisabled()

    // Wait for the checkbox to be checked
    await waitFor(() => expect(screen.getByRole("checkbox")).toBeChecked())

    // Click the now-checked checkbox
    userEvent.click(
        screen.getByRole("checkbox", { name: /mark as uncompleted/ })
    )

    // Wait for the checkbox to be unchecked
    await waitFor(() => expect(screen.getByRole("checkbox")).not.toBeChecked())
})

3. Testing the failure case

To test this failure case, instead of adding logic to conditionally throw in our /task/:id handler, let's override our handler in this test to always throw:

// src/App.test.tsx

it("handles toggling the completed state failing", async () => {
    // Re-use our singleTask handler to display a single task on the page
    server.use(singleTask)

    // Return an error response from the API when we try to call this endpoint
    server.use(
        rest.post(getApiUrl("/task/:id"), (req, res, ctx) =>
            res(ctx.status(500), ctx.json({ message: "Something went wrong" }))
        )
    )

    render(<App />, { wrapper: GlobalWrapper })
    await waitForLoading()

    // Click the checkbox
    userEvent.click(screen.getByRole("checkbox", { name: /mark as completed/ }))

    // Expect the error to display once loading has completed
    await waitFor(() => {
        return expect(
            screen.getByRole("alert").textContent
        ).toMatchInlineSnapshot()
    })

    // Make sure the checkbox stays unchecked
    expect(screen.getByRole("checkbox")).not.toBeChecked()
})

💡 You can mock your API in a given test to always throw, which makes testing failure cases super simple and predictable.

We're done! What did we learn?

In this article, we learned:

How to test POST requests and their effect on the app when they respond.
How to add route parameters to your handler paths.
How to export individual handlers for re-use in multiple tests.
Why it's better to write fewer, longer tests.
Why you should expect certain text content, and how snapshots make it easy.
How to test failure cases by writing handlers that always throw.

Don't use getByTestId 🐙

Jacques Blom — Mon, 21 Dec 2020 07:58:28 +0000

Update: I recently launched a new product called Fudge, which is an AI-powered Shopify page builder & editor. Please check it out if you're interested!

Building interfaces that are accessible to everyone has always been a bit of a black box to me. I do know, however, that not enough apps on the web are built in an accessible way.

Thankfully web standards include a lot of ways that you can make apps accessible. It can be complicated, though. And you can't always tell whether or not you've built something accessible.

One method that has changed how I build my interfaces is using getByRole from React Testing Library instead of getByTestId.

Note: getByRole actually comes from DOM Testing Library, meaning it's available in many of the Testing Libraries. This article will use React Testing Library as an example though.

There are also a few more accessible queries exposed by DOM Testing Library, but we'll focus on getByRole.

If you use getByRole as much as possible, over queries like getByTestId, you will write more accessible code.

Our non-accessible component

In our example, we have a todo list item that you can toggle checked by clicking on the checkbox. Try it out for yourself:

Our Task component is built like this:

If you try to focus on the checkbox with your keyboard to mark the task as completed you'll see that you can't. And it won't work with a screen reader either because we don't have any accessible labels in our UI.

Instead of trying to figure out how to make it accessible by studying the WAI-ARIA spec, let's try and do it using tests!

You can clone the repo to follow along, or just read further.

# Git clone
git clone git@github.com:jacques-blom/accessible-react-tests.git
git checkout tutorial-start

# Install dependencies
yarn

# To start the app
yarn start

Then, run the tests in watch mode:

yarn test --watch

Our current test

Let's first look at our current test:

// src/Task.test.tsx

it("toggles the task checked state", () => {
    render(<Task />)

    // Get the checkbox element
    const checkbox = screen.getByTestId("checkbox")
    const checkIcon = screen.getByTestId("checkIcon")

    // Click it
    userEvent.click(checkbox)

    // Expect the checkbox to be checked
    expect(checkIcon).toHaveStyle("opacity: 1")

    // Click it again
    userEvent.click(checkbox)

    // Expect the checkbox to be unchecked
    expect(checkIcon).toHaveStyle("opacity: 0")
})

Our test doesn't test whether the app is accessible - it just tries to find an element (a div in our case) that has a specific data-testid prop.

Tests using getByTestId don't test accessibility. But we can change our tests to help us build accessible UI.

Step 1: Change our test

We're going to make our app more accessible by taking a TDD approach: first rewriting our test to use getByRole, then changing our code to make the test pass!

Let's rather test our app the way an assistive technology would query our UI. An assistive technology can't just look at our dark circle and determine that it's a checkbox - we actually need to tell it that it's a checkbox.

Instead of querying for the checkbox by testId, we're going to query it by an accessible role:

const checkbox = screen.getByRole("checkbox")

This will try to find an element on the page that has identified itself as a checkbox.

You can find the role that best describes the interactive element you want to test by going through the full list of roles here.

Let's modify our test:

// src/Task.test.tsx

 it("toggles the task checked state", () => {
   render(<Task />);

-  const checkbox = screen.getByTestId("checkbox");
+  const checkbox = screen.getByRole("checkbox");
   const checkIcon = screen.getByTestId("checkIcon");

   // Checked
   userEvent.click(checkbox);
   expect(checkIcon).toHaveStyle("opacity: 1");

   // Not checked
   userEvent.click(checkbox);
   expect(checkIcon).toHaveStyle("opacity: 0");
 });

You'll now see that our test fails. That's because our current element is just a div. DOM Testing Library even gives us a list of possible accessible elements on the page to help us along:

Using getByRole forces you to have accessible elements in your UI.

Step 2: Change our code

Let's start by adding a checkbox input element to our Checkbox component.

const Checkbox = ({ checked, onChange }: CheckboxProps) => {
  return (
    <div
      data-testid="checkbox"
      className="checkbox"
      onClick={() => onChange(!checked)}
    >
      <img
        alt="check icon"
        src="/check.svg"
        style={{ opacity: checked ? 1 : 0 }}
        data-testid="checkIcon"
      />
+     <input type="checkbox" />
    </div>
  );
};

Use native HTML elements as much as possible to make life easy. You will have to deal with overriding browser styling, but the upside is that you get accessibility out of the box.

Next, instead of relying on the div's onClick event, we'll use the checkbox's onChange event:

const Checkbox = ({ checked, onChange }: CheckboxProps) => {
  return (
    <div
      data-testid="checkbox"
      className="checkbox"
-     onClick={() => onChange(!checked)}
    >
      <img
        alt="check icon"
        src="/check.svg"
        style={{ opacity: checked ? 1 : 0 }}
        data-testid="checkIcon"
      />
-    <input type="checkbox" />
+    <input type="checkbox" onChange={(event) => onChange(event.target.checked)} />
    </div>
  );
};

Our test is now passing again!

But we now have an ugly checkbox breaking our design. 😢

So let's add some CSS to fix this.

// src/Task.scss

.checkbox {
  ...
  position: relative;

  > input[type="checkbox"] {
    // Make the input float above the other elements in .checkbox
    position: absolute;
    top: 0;
    left: 0;

    // Make the input cover .checkbox
    width: 100%;
    height: 100%;
  }
  ...
}

Now the checkbox (almost) covers our styled checkbox.

We also need to remove the default margin that comes with the checkbox, and add overflow: hidden to .checkbox so that the checkbox isn't clickable outside our circular design:

// src/Task.scss

.checkbox {
  ...
  // Prevent the input overflowing outside the border-radius
  overflow: hidden;

  > input[type="checkbox"] {
    ...

    // Remove default margin
    margin: 0;
  }
  ...
}

Finally, now that our checkbox input is fully covering our custom checkbox, we can hide it:

// src/Task.scss

.checkbox {
  ...
  > input[type="checkbox"] {
    ...

    // Hide the input
    opacity: 0;
  }
  ...
}

Now we're back to our old design and behavior, and our checkbox is (almost) accessible. Try tabbing to it and hitting the spacebar to toggle the checked state:

I say it's almost accessible because someone using keyboard navigation instead of a mouse can't see if the checkbox is focused. So let's add a focus state:

// src/Task.scss

.checkbox {
  ...
  // Show an outline when the input is focused
  &:focus-within {
    box-shadow: 0 0 0 1px #fff;
  }
  ...
}

We're using :focus-within on .checkbox to apply a style to it if anything inside it is focused:

Always make sure your UI can be navigated using a keyboard. Accessible HTML elements help but make sure you include focus states if you override the default browser outline style.

Finally, we want to label our checkbox with something meaningful so that screen readers can tell the user what the checkbox is for.

We can either add a <label> element, or we can use the aria-label prop. Since we don't want our label to be visible, we'll go for the latter:

// src/Task.tsx

<input
    type="checkbox"
    onChange={(event) => onChange(event.target.checked)}
    // Add an aria-label
    aria-label={checked ? "mark unchecked" : "mark checked"}
/>

To make the label as helpful as possible, we're showing a different label depending on whether the task is checked.

We can now modify our test to find a checkbox with that label, to make sure our label is set. To do this we pass a name parameter to our getByRole call:

const checkbox = screen.getByRole("checkbox", { name: "mark as checked" })

Make sure your UI has helpful labels that can be used by screen readers. Query your elements by those labels in your tests to make sure they're there.

But we need to find it by a different label depending on whether the checkbox is checked or not. We can refactor things a bit to make this easy.

Our final test looks like this:

And here is our final, accessible UI:

What did we improve here in our test?

Added a getCheckbox function to fetch our checkbox by the checked or unchecked label to clean things up.
Expect the checkbox to be checked, instead of checking whether our styled check is visible or not. This makes our code more resilient to change...

How getByRole makes your tests resilient to changing code

Because we are now testing our code in a way that it will be used (find a checkbox input), rather than the way it's built (find an element with a specific test ID), our tests are more resilient to refactoring.

If we completely changed how our UI was built, even if we removed all our UI altogether and just kept the checkbox input, our tests will still pass.

I recently refactored a form from React Hook Form to Formik, and all my tests still worked, even though the underlying code was totally different. Plus, because of how I wrote my tests, my form was completely accessible!

// Detect dark theme var iframe = document.getElementById('tweet-1339572271128653824-434'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1339572271128653824&theme=dark" }

What we've learned

Using getByRole in your tests will test whether your UI is accessible.
getByRole makes your code resilient to refactoring.
When refactoring your UI to make it accessible, use a TTD approach. Write failing tests, then get your tests to pass.
UI is more accessible when it can be easily navigated using a keyboard and has meaningful accessible labels.
Use native browser elements to get out-of-the-box accessibility.

Getting Started with Mock Service Worker

Jacques Blom — Wed, 16 Dec 2020 06:00:14 +0000

Update: I recently launched a new product called Fudge, which is an AI-powered Shopify page builder & editor. Please check it out if you're interested!

I saw a Tweet by Kent C Dodds recently where he mentions the Mock Service Worker library. Now that I’ve worked with it for a bit, I’m in love.

And it looks like a lot of other people are, too. MSW won the “Most Exciting Use of Technology” award at this year’s JavaScript Open Source Awards.

Let’s take a look at what MSW does, and how and why you should use it for your front end tests.

You want to avoid connecting to your real API when running your tests because...

You don’t want to affect your production data when running tests and,
You want to be able to control what the API returns depending on the test you’re running.

But your app still needs to interact with an API to function, meaning you need some sort of fake API to run, that emulates your real API. This is where MSW comes in.

You define handlers using MSW, and it’ll act as your real API, intercepting requests from your front end and responding to them using the handler logic.

But can't I just mock fetch?

Normally if you’re testing a frontend you’re usually either mocking fetch or axios, but MSW acts as an actual server, so your app connects to it as if it’s connecting to your real API.

This means your app isn’t even aware that it’s connecting to a mocked API. To your app, it’s just another day at the office. This guarantees identical behavior in your tests and in production. So...

You’re testing your frontend in as realistic a way as possible and,
You’re also testing how your code is used, rather than how it’s implemented. If you change your data fetching library, everything will still work.

Let's get started!

We have a todo list app that uses the SWR library to fetch a list of todos. It also uses fetch to make a POST request when we insert a todo.

Check out the live example here. (Tasks you insert here are private to you and aren't shared with other users.)

Start by cloning the repo to follow along:

git clone git@github.com:jacques-blom/taskhero-web.git
cd taskhero-web
yarn

Step 1: Set up Mock Service Worker

First, let's install the MSW package.

npm install msw --save-dev
# or
yarn add msw --dev

Next, we create a folder mocks folder, and a file to hold our mocked API handlers.
```
mkdir src/mocks && touch src/mocks/handlers.ts
```
Note that you can use .js files if your project is written in JavaScript, but we're using TypeScript in our Taskhero project.
Now, we can add our first mock. Let's mock our /tasks GET endpoint and just have it return an empty array of tasks.
```
// src/mocks/handlers.ts

import {rest} from 'msw'
import {getApiUrl} from '../components/api'

export const handlers = [
    // Handles a GET /tasks request
    rest.get(getApiUrl('/tasks'), (req, res, ctx) => {
        // Returns an empty array JSON response
        return res(ctx.json([]))
    }),
]
```
💡 Notice here that we're using a getApiUrl util. This returns the full URL that we want to mock. This is important because MSW expects an exact URL match. So if your API fetches data from http://localhost:8080/tasks, you have to specify rest.get('http://localhost:8080/tasks') exactly, not just rest.get('/tasks').
Next, to get it running with Jest (or any other Node-based test runner), create a file called /src/mocks/server.ts.
```
touch src/mocks/server.ts
```

In here, we'll start our server and pass in our handlers.

// src/mocks/server.ts

import {setupServer} from 'msw/node'
import {handlers} from './handlers'

export const server = setupServer(...handlers)

Now we need to start our server when we run our tests. To do this in Jest, we add the following code to a setup file.

Because we're using Create React App in our Taskhero app, we can simply add to our existing src/setupTests.ts file.

Check out the MSW docs for how to set it up without CRA.

// src/setupTests.ts

import {server} from './mocks/server'

// Start the server before all tests.
beforeAll(() => server.listen())

// Reset any handlers that we may add during individual tests,
// so they don't affect other tests.
afterEach(() => server.resetHandlers())

// Stop the server after all tests have run.
afterAll(() => server.close())

Now that our server is running during our test run, our requests in our tests will be intercepted!

Step 2: Writing our first test

Let's create an App.test.tsx file to contain tests for our App component.
```
touch src/App.test.tsx
```

Now, we can write our first test. We'll test that the app displays the loading screen while the data is loading from the /todos endpoint.

import React from 'react'
import {render, screen} from '@testing-library/react'
import App from './App'
import {GlobalWrapper} from './testUtils'

it('shows the loading spinner while data is loading', () => {
    render(<App />, {wrapper: GlobalWrapper})
    expect(screen.getByRole('alert', {name: 'loading'})).toBeInTheDocument()
})

Let's break down what's happening:

First, we render our App component, wrapping it using GlobalWrapper that sets up all the context providers the app needs.

Then, we try to get the spinner and expect it to be in the document.

And now we have our first test!

Sidenote on best practices: Query by role, and use screen

You'll notice two testing techniques here that I think are good practices.

Use screen for all your queries.

Use screen.getByLabelText instead of const {getByLabelText} = render(...). This just makes life a bit easier because you no longer have to keep adding methods to your render destructure.
Query the same way a screen reader would.

This one is a bit more important. Rather than querying by test id, query elements by their accessible name. Not only does this make your tests more resilient to change (even if you completely change how you build your button, it's still a button), it also encourages you to write more accessible code.

These two insights came to me from Kent C. Dodds's excellent article, Common mistakes with React Testing Library, which I highly recommend reading.

Step 3: Dealing with loading states

Now let's test whether the app displays a "No tasks yet" message if the user doesn't have any tasks.

it('shows an alert if there are no tasks', () => {
    render(<App />, {wrapper: GlobalWrapper})
    expect(screen.getByRole('heading', {name: /No tasks yet/i})).toBeInTheDocument()
})

You'll notice our test fails. That's because when we do our expect, the data is still loading. So let's add some code to wait for the loading state to disappear:

-import {render, screen} from '@testing-library/react'
+import {render, screen, waitForElementToBeRemoved} from '@testing-library/react'

-it('shows an alert if there are no tasks', () => {
+it('shows an alert if there are no tasks', async () => {
     render(<App />, {wrapper: GlobalWrapper})
+    await waitForElementToBeRemoved(() => screen.getByRole('alert', {name: 'loading'}))
     expect(screen.getByRole('heading', {name: /No tasks yet/i})).toBeInTheDocument()
 })

Here we use DOM Testing Library's waitForElementToBeRemoved function to wait for loading to finish.

Step 4: Test-specific handlers

Next, we can test whether our app displays an error message if the API returns an error. To do this, we can overwrite our default handler for /tasks with another one that we include directly in our test:

(Remember, we added server.resetHandlers() to run after each test, meaning the following handler will only exist for this test.)

// src/App.test.tsx

import {server} from './mocks/server'
import {rest} from 'msw'
import {getApiUrl} from './components/api'

it('shows an error message if the API returns an error', async () => {
    // Inline handler just for this test
    server.use(
        rest.get(getApiUrl('/tasks'), (req, res, ctx) => {
            // Use ctx.status to return a specific status code
            return res(ctx.status(500), ctx.json({message: 'Internal server error'}))
        }),
    )

    render(<App />, {wrapper: GlobalWrapper})
    await waitForElementToBeRemoved(() => screen.getByRole('alert', {name: 'loading'}))
    expect(screen.getByRole('heading', {name: /error/i})).toBeInTheDocument()
    expect(screen.getByRole('alert', {name: /internal server error/i})).toBeInTheDocument()
})

But our test fails! The test can't find our loading state. Instead, the app just renders the "No tasks yet!" message immediately. This brings us on to one of the gotchas with testing a FE.

Watch out for caching

The issue we're experiencing above is because, the data fetching library we're using, SWR, caches responses. So if it has a cached response it'll return it immediately. A lot of data fetching libraries like SWR, React Query and Apollo Client, have this type of caching behavior that might cause issues.

To get around this, we need to clear SWR's cache between tests. To do this, add the following to afterEach in your test setup file:

+import {cache} from 'swr'

 afterEach(() => {
+    cache.clear()
     server.resetHandlers()
 })

We also need to add dedupingInterval: 0 to the SWRConfig in our GlobalWrapper component that wraps all our tests:

// src/testUtils.tsx

-<SWRConfig value={{fetcher: fetcher, shouldRetryOnError: false}}>
+<SWRConfig value={{dedupingInterval: 0, fetcher: fetcher, shouldRetryOnError: false}}>

Otherwise, SWR is going to wait a bit to see if there are any identical requests between renders that it can do as one call, meaning if we have two tests that call the same endpoint but that expect different responses, SWR is going to combine those two requests as one.

I might write a separate post on how to solve caching issues with all popular data fetching libraries. Let me know what data fetching library you use!

All our tests pass! What's next?

(You can see the completed code with everything we've added here, and see a diff comparison here)

Now you know how to set up MSW to test your front end, and how to write those tests. There is still plenty more to cover. In my next post we'll look at:

Testing POST requests (testing inserting and updating tasks)
Testing requests that have route parameters.
Testing the list of tasks instead of just the empty state
What is useful to test, and what isn't.
Where to put your tests.
And much more.

And in a future post, I'll also cover how to set up MSW with Cypress for end-to-end tests.

If you want to be notified when I release the next posts, follow me on Twitter.

Also feel free to Tweet at me if you have any questions.

If you found this post helpful, and you think others will, too, please consider spreading the love and sharing it.

Forem: Jacques Blom

Mock Service Worker Tutorial Part 2

How to test POST requests with MSW

What we're testing

1. Add the handler

2. Write the test

Testing best practice: Write fewer, longer tests

3. Testing the failure case

Testing best practice: Expecting certain text content, and using snapshots to help you

How to test requests that have route parameters with MSW

What we're testing

1. Add the handlers

2. Write the test

3. Testing the failure case

We're done! What did we learn?

Further reading

Other articles of mine that you might like

Don't use getByTestId 🐙

Our non-accessible component

Our current test

Step 1: Change our test

Step 2: Change our code

How getByRole makes your tests resilient to changing code

What we've learned

Further reading

Getting Started with Mock Service Worker

But can't I just mock fetch?

Let's get started!

Step 1: Set up Mock Service Worker

Step 2: Writing our first test

Sidenote on best practices: Query by role, and use screen

Step 3: Dealing with loading states

Step 4: Test-specific handlers

Watch out for caching

All our tests pass! What's next?