It’s great that our form can be submitted, but we need to get that data to our server to actually save the post to the database. We don’t want to actually make requests to the server during these unit tests, so we’ll mock out the function responsible for doing that and assert that it’s being called with the right data. Then we’ll go ahead and implement that functionality in our form component.

Test React Components with Jest and React Testing Library

Test Drive the API Call of a React Form with React Testing Library

#### post-editor-03-api.js
```js
function Editor() {
  const [isSaving, setIsSaving] = React.useState(false)
  function handleSubmit(e) {
    e.preventDefault()
    setIsSaving(true)
  }
  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="title-input">Title</label>
      <input id="title-input" />

      <label htmlFor="content-input">Content</label>
      <textarea id="content-input" />

      <label htmlFor="tags-input">Tags</label>
      <input id="tags-input" />

      <button type="submit" disabled={isSaving}>
        Submit
      </button>
    </form>
  )
}
```

Instructor: [00:01] When the user submits our form, we're going to call this `handleSubmit`. We want to actually save this post that the user is editing in our `Editor`. We're going to have some sort of `savePost`. We want a new post, some new post data in here, that's all derived from the elements of our form.

```js
function Editor() {
  const [isSaving, setIsSaving] = React.useState(false)
  function handleSubmit(e) {
    e.preventDefault()
    setIsSaving(true)
    savePost(newPost)
  }
  ...
}
```

[00:17] That `savePost` is going to come from an API module. We'll have `savePost` from our API. To accomplish this, we're going to need to mock out the `savePost` method from the API module because we don't want to actually make an HTTP request in our test.

```js
import{savePost} from './api'
```

[00:33] Let's go ahead and make this happen. I'll clear this all back up. We'll test drive this. The first thing that I'm going to need to do is import our `savePost` from the API. Then I'm going to add a `jest.mock` for that API right here.

[00:48] With a mocked version of this `savePost`, I'm going to give this an alias as `mockSavePost`.

#### tdd-03-api.js

```js
import {savePost as mockSavePost} from '../api'
import {Editor} from '../post-editor-03-api'

jest.mock('../api')
```

With that, I'm going to say, "Hey, `mockSavePost`, when you're called, I want you to `mockResolvedValueOnce`." We don't really have a value that we're going to resolve to right now. We'll just leave that blank.

```js
test('renders a form with title, content, tags, and a submit button', () => {
  mockSavePost.mockResolvedValueOnce()
  const {getByLabelText, getByText} = render(<Editor />)

  ...
}
```

[01:08] The key here is that it's returning a promise that resolves. Here, we are mocking that. Now, we want to make an assertion that it's being called properly. We'll expect `mockSavePost` to have been called with...This is going to need to be called with the `postData`. Where are we going to get that post data? It's going to come from the inputs from the user.

```js
test('renders a form with title, content, tags, and a submit button', () => {
  mockSavePost.mockResolvedValueOnce()
  const {getByLabelText, getByText} = render(<Editor />)


  getByLabelText(/title/i)
  getByLabelText(/content/i)
  getByLabelText(/tags/i)
  const submitButton = getByText(/submit/i)

  fireEvent.click(submitButton)

  expect(submitButton).toBeDisabled()

  expect(mockSavePost).toHaveBeenCalledWith()
})
```

[01:29] What I'm going to do is I'm going to say `value` equals test title. For the content, we'll have test content. For the tags, we'll say, tag one and tag two as the users input. Then we can say `mockSavePost`s should be called with a `title` that is test title, `content` that is test content, and `tags` that is an array of tag one and tag two. The user inputs a comma-separated list of tags. When we save it, we turn that comma separated list into an array. That's what we're going for here.

```js
test('renders a form with title, content, tags, and a submit button', () => {
  mockSavePost.mockResolvedValueOnce()
  const {getByLabelText, getByText} = render(<Editor />)


  getByLabelText(/title/i).value = fakePost.title
  getByLabelText(/content/i).value = fakePost.content
  getByLabelText(/tags/i).value = fakePost.tags.join(', ')
  const submitButton = getByText(/submit/i)

  fireEvent.click(submitButton)

  expect(submitButton).toBeDisabled()

  expect(mockSavePost).toHaveBeenCalledWith({
    title: 'Test Title',
    content: 'Test content',
    tags: ['tag1', 'tag2']
  })
  expect(mockSavePost).toHaveBeenCalledTimes(1)
})
```

[02:06] Another thing we want is to expect that the `mockSavePost` to have been called times once and only once. If we save that and open up our test, we're going to see that it is indeed failing because `mockSavePost` is not being called at all.

[02:22] Let's go ahead and make this pass. I'm going to import `savePost` from our API module. Right here, we'll call `savePost`. We invoke that. Now, we're going to see that our number of calls is one. We're still not calling it with anything. Let's go ahead and call it with our `title`, `content` and `tags`. Where am I going to get those?

#### post-editor-03-api.js

```js
function Editor() {
  const [isSaving, setIsSaving] = React.useState(false)
  function handleSubmit(e) {
    e.preventDefault()
    setIsSaving(true)
    savePost({
      title,
      content,
      tags
    })
  }
  ...
}
```

[02:45] This `handleSubmit` is on our form. We have that form DOM node from the event, that's `event.target`. We can get access to all of the elements inside of this form from that form node if we give each one of these a name. We'll say `name`, title. We'll add a `name` content for this one and a `name` tags for this one.

```js
function Editor() {

  ...

 return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="title-input">Title</label>
      <input id="title-input" name="title" />

      <label htmlFor="content-input">Content</label>
      <textarea id="content-input" name="content" />

      <label htmlFor="tags-input">Tags</label>
      <input id="tags-input" name="tags" />

      <button type="submit" disabled={isSaving}>
        Submit
      </button>
    </form>
  )
}
```

[03:09] For that, I can now say `title` `content` `tags` = `e.target.elements`. That target is the form and `elements` is a property on a form DOM node that has properties for all of the elements by their name. We have the `title` node, the `content` note, and the `tags` node.

[03:26] To get the values, we'll say `title.value`, `content.value`, and then `tags.value`. Remember, the user is going to enter these in as comma separated values. We want this to be an array. Let's say `.split` these by a comma. We'll `map` each one of those elements to `t.trim`, so that we get rid of any white space. Now let's save that. Our test is passing. Excellent.

```js
function Editor() {
  const [isSaving, setIsSaving] = React.useState(false)
  function handleSubmit(e) {
    e.preventDefault()
    const {title, content, tags} = e.target.elements
    setIsSaving(true)
    savePost({
      title: title.value,
      content: content.value,
      tags: tags.value.split(',').map(t => t.trim()),
    })
  }
  ...
}
```

[03:53] That's the red, green part of our red, green, refactor cycle. Let's go ahead and look at some things to refactor. I'm actually pretty happy with the implementation. Let's take a look at our test. I'm not super thrilled with the duplication between these strings here.

[04:07] What I'm going to do is create a `fakePost` right here. We'll have a `title` for that test title. Our `content` will be test content. Our `tags` will be that array tag 1 and tag 2. Right here, we can say, `fakePost.title`, `fakePost.content`, and then `fakePost.tags` join with the comma.

#### tdd-03-api.js

```js
test('renders a form with title, content, tags, and a submit button', () => {
  mockSavePost.mockResolvedValueOnce()
  const fakeUser = {id: 'user-1'}
  const {getByLabelText, getByText} = render(<Editor user={fakeUser} />)
  const fakePost = {
    title: 'Test Title',
    content: 'Test content',
    tags: ['tag1', 'tag2'],
  }
  getByLabelText(/title/i).value = fakePost.title
  getByLabelText(/content/i).value = fakePost.content
  getByLabelText(/tags/i).value = fakePost.tags.join(', ')
  const submitButton = getByText(/submit/i)

  ...
}
```

[04:32] Down here, we can simply pass in our `fakePost`. We'll open up our test, make sure that's still passing.

```js
...

expect(submitButton).toBeDisabled()

expect(mockSavePost).toHaveBeenCalledWith(fakepost)
expect(mockSavePost).toHaveBeenCalledTimes(1)
```

Excellent. There's actually a feature that we probably should have in this that I'm going to add in here. That is, it should be called with the creating user's ID as well. We're going to spread this across, and we'll have an `authorId.`.

```js
expect(mockSavePost).toHaveBeenCalledWith({
  ...fakePost,
  authorId: fakeUser.id,
})
```

[04:53] That is going to need to come from somewhere. We're going to make a fake user.ID right here. We'll come up here. We'll make a `fakeUser`. That `fakeUser` will be an object with an ID. That is user 1. Now, the `Editor` needs to have access to this `fakeUser` somehow.

```js
test('renders a form with title, content, tags, and a submit button', () => {
  mockSavePost.mockResolvedValueOnce()
  const fakeUser = {id: 'user-1'}
  const {getByLabelText, getByText} = render(<Editor user={fakeUser} />)

  ...
}
```

[05:10] We're going to pass it as a prop user as this `fakeUser`. The editor can accept that user as a prop. Then when we save the post, we'll have the `authorId.` set to the user.ID. Now our test is passing again.

#### post-editor-03-api.js

```js
function Editor() {
  const [isSaving, setIsSaving] = React.useState(false)
  function handleSubmit(e) {
    e.preventDefault()
    const {title, content, tags} = e.target.elements
    setIsSaving(true)
    savePost({
      title: title.value,
      content: content.value,
      tags: tags.value.split(',').map(t => t.trim()),
      authorId: user.id,
    })
  }
  ...
}
```

[05:25] In review, what we wanted to accomplish here is we have the `savePost` method for our API to save a post to our backend. We want to save the post that the user's created in the submit handler. We need to pass along all the data, the `title`, the `content`, the `tags`, and the user ID as the `authorId.` here.

[05:44] To accomplish this, we went into our tests. We created a `fakeUser` and a `fakePost`. We set the value to each one of these DOM nodes, and then we submit the button. We verify that `savePost` is called with all the properties from the `fakePost` as well as the author's ID. We verify that the `mockSavePost` is only called once.

[06:03] We get this `mockSavePost` by using the `jest.mock` API so that it automatically creates Jest mock functions for each of the functions that are exposed by the API module. Here, we set up the implementation of `mockSavePost` to return the promise that results.

[06:18] One last thing that I'm going to do here is I'm going to add an `afterEach`, and we'll say `jest.clearAllMocks`. That way, all of the mocks that are being called inside of each of these tests that are automatically set up by Jest are cleared between every one of these tests, so that the tests remain isolated and they don't mock up with one another as they're calling these mock functions.

#### tdd-03-api.js

```js
afterEach(() => {
  jest.clearAllMocks()
})
```

[06:39] I'm also going to make a slight change here where I want to take this. We'll make this a new post, and then we'll make a new post variable here and just paste that there.

#### post-editor-03-api.js

```js
function Editor({user}) {
  const [isSaving, setIsSaving] = React.useState(false)
  function handleSubmit(e) {
    e.preventDefault()
    const {title, content, tags} = e.target.elements
    const newPost = {
      title: title.value,
      content: content.value,
      tags: tags.value.split(',').map(t => t.trim()),
      authorId: user.id,
    }
    setIsSaving(true)
    savePost(newPost)
  }

  ...
}
```


If you want to ship your applications with confidence - and of course you do - you need an excellent suite of automated tests to make absolutely sure that when changes reach your users, nothing gets broken. To get this confidence, your tests need to realistically mimic how users actually use your React components. Otherwise, tests could pass when the application is broken in the real world.

In this course, we’ll write a series of render methods and run a range of tests to see how we can get the confidence we’re looking for, without giving up maintainability or test run-speed.

What's changed in Test React Components with Jest and React Testing Library

Intro to Test React Components with Jest and React Testing Library

Let’s start basic by using ReactDOM to render a simple React component to a <div> we create ourselves and assert that it’s rendering the right thing based on the props we provide.

Render a React Component for Testing

The Jest DOM library provides really useful extensions to jest’s built-in assertion library that will make it easier for us to write our test assertions (like toHaveTextContent). Let’s see how to use that in our project.

Use Jest DOM for Improved Assertions

Our tests are currently tightly coupled to the implementation of our component’s element structure. A refactor to that structure wont break our application, but will definitely break our tests because we’re testing implementation details. Let’s use DOM Testing Library to create a custom render function that will give us some helpful utilities for searching for elements in the DOM in the same way a user would.

Use DOM Testing Library to Write More Maintainable React Tests

Let’s create a simple render method to be able to reuse this functionality for our other tests. The render method we’ve created is similar to [the render method](https://testing-library.com/docs/react-testing-library/api#render) that’s provided by React Testing Library. Let’s swap our implementation to that!

Use React Testing Library to Render and Test React Components

While you’re writing your tests it can be helpful to see what the DOM looks like. You can do this with React Testing Library’s debug function which will log a formatted and syntax highlighted state of the DOM at the time it is called.

Debug the DOM State During Tests using React Testing Library’s debug Function

The fireEvent utility in React Testing Library supports all the events that you regularly use in the web (change, click, etc.). Let’s see how we can test our change event handler with an input.

Test React Component Event Handlers with fireEvent from React Testing Library

The User Event module is part of the Testing Library family of tools and lets you fire events on DOM nodes that more closely resemble the way your users will interact with your elements. Let’s refactor our fire event usages to use that instead.

Improve Test Confidence with the User Event Module

Sometimes it can be useful to change the props of a component you’ve rendered and make assertions about what’s rendered after that prop change has taken place. Let’s see how to go about doing this with React Testing Library.

Test Prop Updates with React Testing Library

It’s pretty straightforward to assert that a certain element is rendered with react-testing-library, but what if we want to ensure that something is NOT being rendered. For example, if we re-render our component with a different maximum amount leading to the error message being hidden. Let’s see how we can use the query* APIs from react-testing-library to assert that certain elements are not rendered.

Assert That Something is NOT Rendered with React Testing Library

While not all of accessibility testing of a web application can be automated, much of it can be and quite easily using [axe-core](https://github.com/dequelabs/axe-core) and [jest-axe](https://github.com/nickcolley/jest-axe). Let’s see how to integrate this with React Testing Library to help catch common accessibility issues.

Test Accessibility of Rendered React Components with jest-axe

If you have a component that makes HTTP requests, you’ll probably want to mock those out for UI unit and integration tests. Let’s see how to use jest’s built-in mocking capabilities to do that.

Mock HTTP Requests with jest.mock in React Component Tests

Mocking an API module works, but it's incomplete because we have to make all these assertions that we're calling it properly and then we'd need to write some other tests for the API module itself to make sure that it responds properly to those calls. 

In this lesson, I'll show you how you can use a package called [MSW](https://mswjs.io/) to intercept and handle those HTTP requests instead so we can get a great deal more confidence.

[Get the code on GitHub](https://github.com/kentcdodds/react-testing-library-course/blob/46d2608caaa404476c9224cd136aea270a739e6d/src/__tests__/http-msw-mock.js)

Mock HTTP Requests with MSW

There are some situations where you want to focus your tests on a particular component and not any of its children. There are other situations where you want to mock out the behavior of components that your component renders. In the case of react-transition-group, we don’t want to have to wait until the transition has completed before we can go on with our tests. Let’s see how we can mock the implementation of react-transition-group using jest.mock to make our tests more reliable and easier to write and maintain.

Mock react-transition-group in React Component Tests with jest.mock

If the user experiences an error while using your application you may want to send information to a monitoring tool to ensure you can be made aware of the error and deal with it as quickly as possible. Let’s see about testing a component that is responsible for this componentDidCatch error boundary using React Testing Library.

Test componentDidCatch Handler Error Boundaries with React Testing Library

When testing an error boundary, your console will be filled with console.error calls from React. Those can be a real distraction from the rest of the output for your tests. Let’s clean those up with jest.spyOn.

Hide console.error Logs when Testing Error Boundaries with jest.spyOn

Our error boundary has some other use cases that it supports and we should try to make sure our tests cover all those use cases, so let’s add a test to make sure the recovery feature of our error boundary works properly.

Ensure Error Boundaries Can Successfully Recover from Errors

We have a bit of repetition in our rerender calls here and it would be nice if we could avoid that. Let’s use the wrapper option for React Testing Library so we can avoid the repetition in our rerender calls.

Use React Testing Library’s Wrapper Option to Simplify using rerender

Normally using Test Driven Development (TDD) with UI is really difficult because testing utilities for UI often tie your tests closely to the implementation. Because React Testing Library is not this way, we can actually use it to TDD our UI. Let’s build the structure of a form using TDD with React Testing Library.

Test Drive the Development of a React Form with React Testing Library

Now that we have our react form structure written using TDD, let’s take it a step further and TDD our form’s submission with an onSubmit handler as well.

Test Drive the Submission of a React Form with React Testing Library

Once the data has been saved on the server, we’ll want to redirect the user to the home screen with react-router’s <Redirect /> component. Let’s go ahead and mock that component as well and verify that it’s being rendered with the correct props. We’ll have to make our test asynchronous so we can make that assertion because the <Redirect /> component is rendered after the async call happens.

Test Drive Mocking react-router’s Redirect Component on a Form Submission

Our post should probably have a creation date associated with it (typically you’ll add this on the server, but for the purposes of our example, we’ll do it on the client). Dates are notoriously challenging to test. There are existing libraries that help, but often you can get close enough to the desired effect for your assertions. Let’s go ahead and test that a correct creation date has been set for our posts.

Test Drive Assertions with Dates in React

A really important aspect of TDD is the refactor phase. A critical piece to making your tests easier to maintain is using code structure and values to communicate what is important and what is not. We’ll use data generation with [test-data-bot](https://github.com/jackfranklin/test-data-bot) to communicate that the specific data values are irrelevant and it’s just what kind of data it is. Let’s refactor our tests to communicate this effectively.

Use Generated Data in Tests with tests-data-bot to Improve Test Maintainability

We have the happy path covered for our post editor component, but what happens if there’s an error in saving the user’s information? We should probably show them an error message and give them the chance to try again. Let’s add a new test for this error case and implement some error handling.

Test Drive Error State with React Testing Library

We’ve finished with our post editor component, but let’s not forget the refactor phase! We have a bunch of duplicate logic between our two tests. When you have multiple tests with duplicate logic, it becomes hard for folks who come to maintain the tests later to identify what the differences between the tests are. This makes it harder to understand what the different features of the component are. So let’s refactor the tests slightly so we can communicate clearly what the important and unique parts of the tests are to make it easier for future maintainers.

Write a Custom Render Function to Share Code between Tests and Simplify Tests

Mocking the <Redirect /> component in react-router works, but it’s imperfect because we don’t know for sure that the user will be redirected properly. Alternatively, we can render our component within a Router with a custom implementation of a history via createMemoryHistory. Then we can make assertions on that history object.

Test React Components that Use the react-router Router Provider with createMemoryHistory

If the user enters a bad URL or there’s some kind of routing error, we should show the user a helpful error page. Let’s see how we can test that our page is wired up with the router properly to do this.

Initialize the `history` Object with a Bad Entry to Test the react-router no-match Route

Many of our components need (or will eventually need) the router context from the router provider. Let’s write a custom render method that looks and acts like the render method from React Testing Library but adds features for our router so we don’t have to concern ourselves about the implementation detail of the router.

Create a Custom render Function to Simplify Tests of react-router Components

Similar to react-router, we can render our component under test with the redux provider, our full redux store, and then we can interact with our component in the same way the user would and be confident that our component, action creators, and reducers are all working properly.

Test a Redux Connected React Component

There are definitely some scenarios where you want to test what a component will do given certain state in the store. Let’s see how we can initialize our redux provider with a store that has some custom initialized data. One thing that I should note here is that while it can be useful to do this, make sure you at least have one test that verifies that you can  into this state in the first place.

Test a Redux Connected React Component with Initialized State

It’s very common for our components to use state from the redux store (or to be refactored to use it eventually). Having to change our tests every time we do this would be frustrating. Let’s see how we can write a render method we could use to not worry about that implementation detail when it’s irrelevant for our tests. This could be combined with the custom render method for the router to be a single render method that supports all providers our components need.

Create a Custom Render Function to Simplify Tests of Redux Components

We’ve got a custom useCounter hook here and we want to make sure the increment and decrement functions it returns will update the count state that it returns. Because hooks must be run within the render phase of a component, we’ll create a simple component that simply uses the hook and render that component. One catch is that whenever there’s a state update in your tests, React needs you to wrap that in a call to act. We don’t have to do that for regular component tests that use React Testing Library utilities because those utilities manage the act call internally, but since we’re calling these state updater functions ourselves, we have to wrap things in act. Let’s do that for our useCounter hook.

Test a Custom React Hook with React’s Act Utility and a Test Component

Once we add tests for all the use cases of our hook, we’ll notice a bunch of common setup, so let’s put that in a setup function.

Write a Setup Function to Reduce Duplication of Testing Custom React Hooks

That setup function is pretty handy. Seems like a good opportunity for an abstraction. Well, we already have one! It’s called React Hooks Testing Library. Let’s swap our setup function for the renderHook function from @testing-library/react-hooks.

Test a Custom React Hook with renderHook from React Hooks Testing Library

Just like React Testing Library, React Hooks Testing Library has a rerender function which can be useful for testing changes to props. Let’s test what happens if the step option changes for our hook.

Test Updates to Your Custom React Hook with rerender from React Hooks Testing Library

When you use a React Portal, much of your component can be rendered outside the main DOM tree. Let’s see how we can use utilities provided by React Testing Library to allow us to select elements within the portal. To perform actions and assert on what’s rendered.

Test React Portals with within from React Testing Library

Sometimes your react component may need to do some cleanup work in the return value from useEffect or useLayoutEffect, or the componentWillUnmount lifecycle method for class components. Luckily for us, as far as React Testing Library is concerned, whichever of those you use is an implementation detail, so your test looks exactly the same regardless of how you implement it. Check out how you can test that simply with React Testing Library and a <Countdown /> component.

Test Unmounting a React Component with React Testing Library

You can get a huge amount of confidence and coverage from integration tests that test an entire page, or even your entire app. Let’s write a test that renders our whole app using React Testing Library and navigate around it like a normal user would. These tests are typically a bit longer, but they provide a huge amount of value.

Write React Application Integration Tests with React Testing Library

By using some of the get* queries, we’re assuming that those elements will be available on the page right when we execute the query. This is a bit of an implementation detail and it’d be cool if we could not make that assumption in our test. Let’s swap all those for find* queries.

Improve Reliability of Integration Tests using find* Queries from React Testing Library

Let’s take things a step closer to the way our app is used by using the User Event module for interacting with our app. Once we’ve done all this implementation detail-free testing, we’ll find out that we can drastically change the implementation of our app and our tests can give us confidence that our changes were successful. That’s fantastic!

Test Drive the API Call of a React Form with React Testing Library

Transcript

Test Drive the API Call of a React Form with React Testing Library