Summer’s over — what’s your move? Join Pro for 50% off using code [MAKEITHAPPEN](https://www.codecademy.com/checkout?periods=year&plan_id=proGoldAnnualV2&discountCode=MAKEITHAPPEN)


Learn how to test React components with React Testing Library.

React Testing Library

In the previous exercise, we learned about the `.findByX` query methods that allow us to test components that render asynchronously. But what about components that disappear asynchronously? 

Look at the example below. We have a component that displays a header. This header is removed after 250 ms when the button "Remove Header" is clicked. 

```js
// In header.js:
export const Header = () => {
 const handleClick = () => {
   setTimeout(() => {
     document.querySelector('h1').remove()
   }, 250);
 };
 return (
   <div>
     <h1>Hey Everybody</h1>
     <button onClick = {handleClick}>Remove Header</button>
   </div>
 );
};
```

How would you test that the header is removed? Using `screen.findByX()` methods won't work because there won't be an element to query once it's removed! Using only `screen.queryByX()` methods won't work either, as the component is removed asynchronously. 

Fortunately, RTL provides another function that can be used for asynchronous testing that will be perfect for this scenario - the `waitFor()` function. In order to use this function, we need to import it from  `@testing-library/react`.

```js
import { waitFor } from '@testing-library/react';
```

As with the other async functions, the `waitFor()` function returns a Promise, so we have to preface its call with the `await` keyword. It takes a callback function as an argument where we can make asynchronous function calls, perform queries, and/or run assertions. 

```js
await waitFor(() => {
  expect(someAsyncMethod).toHaveBeenCalled();
  const someAsyncNode = screen.getByText('hello world');
  expect(someAsyncNode).toBeInTheDocument();
});
```

Now, let's get back to the example. To test that a component disappears asynchronously, we can combine the `waitFor()` function with `.queryByX()` methods:

```js
import { waitFor, render, screen } from '@testing-library/react';
import '@testing-library/jest-dom';
import userEvent from '@testing-library/user-event';
import { Header } from './heaader.js'

it('should remove header display', async () => {
  // Render Header
  render(<Header/>)
  // Extract button node 
  const button = screen.getByRole('button');
  // click button
  userEvent.click(button);

  // Wait for the element to be removed asynchronously
  await waitFor(() => {
    const header = screen.queryByText('Hey Everybody');
    expect(header).toBeNull()
  })
});
```

In our unit test, the header will be removed 250ms after the button has been clicked. The callback function inside `waitFor()` confirms this by querying for this element and then waiting for the `expect()` assertion to pass.

The `waitFor()` method can also optionally accept an `options` object as a second argument. This object can be used to control how long to wait for before aborting and much more. Though the details of this `options` object are beyond the scope of the lesson, you can read more about it in the [docs](https://testing-library.com/docs/dom-testing-library/api-async/#waitfor).

The waitFor() method

When we write tests for our applications, we often have to simulate user interaction with our application. This means we need to often work with the DOM elements to test how it reacts to user actions. To do so, we first have to query for and extract the DOM nodes from our virtually rendered components. Then, we can check and see if the extracted DOM nodes were rendered as expected. Fortunately for us, RTL has many built-in query methods that greatly simplify this process. In this exercise, we will cover the `.getByX` query methods. 

There are a number of `.getByX` query methods to choose from, and they are all accessible as methods on the `screen` object. Look at the example below, the `.getByText()` method is used to extract a DOM element with text that matches a specified string.

```js
import { render, screen } from '@testing-library/react';

const Button = () => {
    return <button type="submit" disabled>Submit</button>
};

it('Rendered a "Submit" button', () => {
  // Render the Button component
  render(<Button/>);
  // Extract the <button>Submit</button> node
  const button = screen.getByText('Submit'); 
});
```

If there is a match, meaning that it was able to find a matching node for the query, it will return the element. Otherwise, it will throw an error!

Similarly, another method is `.getByRole()`, which allows us to extract a DOM node by its role type. Look at the example below; it shows us another way we can query for the `<button>` element using `.getByRole()`.

```js
import { render } from '@testing-library/react';

const Button = () => {
    return <button type="submit" disabled>Submit</button>
};

it('extracts the button DOM node', () => {
  // Render the Button component
  render(<Button/>);
  // Extract the <button>Submit</button> node
  const button = screen.getByRole('button'); 
});
```

RTL has a bunch of these `.getByX` methods, but instead of memorizing them all, it is best to look at the [docs](https://testing-library.com/docs/queries/about/) to find the one that best suits your needs.

Now that we know how to query DOM nodes, we can test them using [Jest assertions](https://jestjs.io/docs/expect). Recall that in the first exercise, we saw the assertion `expect.toBeChecked()`. This isn't part of the regular set of Jest matchers, but instead is an extension provided by the `testing-library/jest-dom` library. 

Just as before, if you've initialized your application with `create-react-app` as we have, `jest-dom` is included as a default dependency. Without configuration, we can use it out of the box. 

The entire library can then be imported into our test file like so:

```js
import '@testing-library/jest-dom';
```

Here is an example of the `expect.toBeDisabled()` matcher being used to test a DOM node extracted with the `screen.getByRole()` method.

```js
import { render } from '@testing-library/react';
import '@testing-library/jest-dom';

const Button = () => {
    return <button type="submit" disabled>Submit</button>
};

it('shows the button as disabled', () => {
  // render Button component
  render(<Button/>);
  // Extract <button>Submit</button> Node
  const button = screen.getByRole('button');
  // Assert button is disabled
  expect(button).toBeDisabled();
});
```

Once again, there are many different Jest matchers. In this lesson, we'll get a chance to see a number of the most common ones. However, instead of memorizing all of them, it is best to peruse the [`jest-dom` docs](https://github.com/testing-library/jest-dom) as you write your test.

> Note: If you want to install `jest-dom` locally and you did not use `create-react-app` to initialize your project, you can use the following command to install it as one of your project's `devDependencies`: 
```bash
npm install --save-dev @testing-library/jest-dom
```

Querying with RTL

Now, let's discuss querying for asynchronous elements. Imagine we're testing an application comprising components that perform asynchronous operations, such as fetching data from an API, triggering animations, or executing delayed rendering. How would we write tests that will wait for these elements to appear?

We can use [`.findByX`](https://testing-library.com/docs/queries/about/) methods. The `.findByX` methods are used to query for asynchronous elements, which will eventually appear in the DOM. The `.findByX` methods work by returning a Promise, which resolves when the queried element renders in the DOM. As such, the `async`/`await` keywords can be used to enable asynchronous logic.

Let's look back at the program again. Recall that the header has a 500ms delay. We want to confirm that the `header` will display the text `'Goodbye'` after the button is clicked. 

```js
// Changes header text after interval of 500ms
const handleClick = () => {
  setTimeout(() => {
      setText('Goodbye!');
  }, 500);
};
```

We can write our test like this. This example uses the `userEvent` library, which will be covered in depth in the next exercise, to simulate clicking on the button.

```js
import App from './components/App';
import { render, screen } from '@testing-library/react';

it('should show text content as Goodbye', async () => {
  // Render App
  render(<App />);
  // Extract button node 
  const button = screen.getByRole('button');
  // click button
  userEvent.click(button);
  // Wait for the text 'Goodbye!' to appear
  const header = await screen.findByText('Goodbye!');
  // Assert header to exist in the DOM
  expect(header).toBeInTheDocument();
});
```

In the example above, we use `.findByText()` since the `'Goodbye!'` message does not render immediately. This is because our `handleClick()` function changes the text after an interval of 500ms. So, we have to wait a bit before the new text is rendered in the DOM.

Observe the `async` and `await` keywords in the example above. Remember that `findBy` methods return a Promise, and thus, the callback function that carries out the unit test must be identified as `async` while the `screen.findByText()` method must be preceded by `await`.

> Note: Before you start the instructions, go to the **AddThoughtForm.js** file and observe the `handleSubmit()` function. For just this exercise, we've modified this function slightly with a `setTimeout()`, so that the thoughts get added asynchronously. Go ahead and post a thought in the App. Notice how there is a slight lag when the thought gets posted after you click the `Add` button.

Querying Asynchronous Components

Just like Jest, `create-react-app` includes React Testing Library by default. Since we initiated our project using `create-react-app`, we can immediately start utilizing React Testing Library without any additional setup.

To start, we'll take a look at two core objects, `render` and `screen`.

* `render()` is a function that we can use to virtually render components and make them available in our unit tests. Similar to `ReactDOM.render()`, RTL's `render()` function takes in JSX as an argument.
* `screen` is a special object which can be thought of as a representation of the browser window. We can make sure that our virtually rendered components are available in the test by using the `screen.debug()` method, which prints out all the DOM contents.

The `screen` object has a few other useful methods that we'll cover in the upcoming exercises, but for now, let's look at an example.

Look at the code snippet below. It shows the output of a unit test that prints out the DOM contents of the `Greeting` component.

```js
import { render, screen } from '@testing-library/react'

const Greeting = () => {
 return (<h1>Hello World</h1>)
};

it('prints out the contents of the DOM' () => {
   render(<Greeting />);
   screen.debug();
});

// Output:
<body>
 <div>
   <h1>
     Hello World
   </h1>
 </div>
</body>
```

After importing the `render` and `screen` values from `'@testing-library/react'`, a test is created using the `it()` function from the [Jest testing framework](https://jestjs.io/docs/getting-started). Inside, the `<Greeting>` component is virtually rendered, and then the resulting virtual DOM is printed via the `screen.debug()` method.

Notice how the output shows the rendered contents of `<Greeting>` (an `<h1>` element) and not the component itself. As was mentioned in the first exercise, React Testing Library strives to produce a testing environment that is as close to the user's experience as possible.

Now, let's get started with testing the Passing Thoughts application!

> Note: If you want to install React Testing Library locally and you did not use `create-react-app` to initialize your project, you can use the following command to install it as one of your project's `devDependencies`: 
```bash
npm install --save-dev @testing-library/react
```

The Render and Screen Objects

So far, we've learned how to query and extract the different DOM nodes from our React components. Now, it's time for us to learn how to mimic user interactions, such as clicking a checkbox and typing text. Once again, this entire process has been made easier for us with the help of another library in the `@testing-library` suite: `@testing-library/user-event`.

This library exports a single object, `userEvent`, that can be imported in a test file like so:

```js
import userEvent from '@testing-library/user-event';
```

The `userEvent` object contains many built-in methods that allow us to mimic user interactions. Typically, they follow the same syntax pattern:

```js
userEvent.interactionType(nodeToInteractWith);
```

Here is an example where we mimic a user filling in a text box. Note that in this case, a second argument is provided as the text to be typed into the box.

```js
import React from 'react';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import '@testing-library/jest-dom';

const GreetingForm = () => {
  return(
    <form>
      <label htmlFor="greeting">
        Greeting:
      </label>
      <input type="text" id="greeting" />
      <input type="submit" value="Submit" />
    </form>
  );
};

it('should show text content as Hey Mack!', () => {
  // Render the component to test
  render(<GreetingForm />);
  // Extract the textbox component
  const textbox = screen.getByRole('textbox');
  // Simulate typing 'Hey Mack!'
  userEvent.type(textbox, 'Hey Mack!');
  // Assert textbox has text content 'Hey Mack!'
  expect(textbox).toHaveValue('Hey Mack!');
});
```

In the example above, the `userEvent.type()` method is used, which accepts a DOM node to interact with (`textbox`) and a string to type into that node (`'Hey Mack!'). 

The `userEvent` object has methods for [simulating clicks (`userEvent.click()`)](https://testing-library.com/docs/ecosystem-user-event/#clickelement-eventinit-options), [hovering (`userEvent.hover()`)](https://testing-library.com/docs/ecosystem-user-event/#hoverelement), and much more. Once again, instead of memorizing all of these, it is recommended that you read the [docs](https://github.com/testing-library/user-event) to find the method best suited for your needs.

> Note: If you want to install `user-event` locally and you did not use `create-react-app` to initialize your project, you can use the following command to install it as one of your project's `devDependencies`: 
```bash
npm install --save-dev @testing-library/user-event
```

Mimicking User Interactions

In this lesson, you will learn how to test your React components with the [**R**eact **T**esting **L**ibrary (RTL)](https://testing-library.com/docs/react-testing-library/intro/). React Testing Library is a UI-layer testing framework that helps us ensure that our React components are rendering and behaving properly.

The main advantages of RTL over other UI-layer testing frameworks are:
* It is built explicitly for testing React components.
* It allows us to test our components in a way that mimics real user interactions. 

The logic behind this is that a user will not care about the implementation details of a React component, such as the component's state, the props passed to it, etc. The user will only care about whether or not they are able to use the app. We should test our application with these same motivations.

Before we jump into the lesson, let's take a quick look at an example that shows off the power and elegance of the React Testing Library. 

> Note: this lesson assumes that you have a basic understanding of the [Jest](https://jestjs.io/docs/getting-started) testing framework.

Take a moment to observe the code sample below. It shows a `GroceryList` component with a few items. You can click on the checkboxes to mark that you've added one of these items to your cart. You can see the code for this component in the file `GroceryList.js`. 

```js
const GroceryList = () => {
  return (
  <div>
    <h1>Grocery List</h1>
      <ul>
        <li>
          <label htmlFor="item1">Apples</label>
          <input type="checkbox" id="item1"/>
        </li>
        <li>
          <label htmlFor="item2">Milk</label>
          <input type="checkbox" id="item2"/>
        </li>
        <li>
          <label htmlFor="item3">Cereal</label>
          <input type="checkbox" id="item3"/>
        </li>
      </ul>
    </div>
  )
};

export default GroceryList;
```

Next, let's look at a unit test using RTL. Observe how it mimics a user clicking the first checkbox:

```js
import { render, screen, cleanup } from '@testing-library/react';
import GroceryList from './components/GroceryList';
import userEvent from '@testing-library/user-event';

it('should mark the first checkbox as checked', () => {
  // render the grocery list
  render(<GroceryList />);
  // grab the apple item
  const appleItem = screen.getByLabelText('Apples');
  // simulate a "click" on the apple checkbox
  userEvent.click(appleItem);
  // assert that the apple checkbox was checked
  expect(appleItem).toBeChecked();
});
```

Can you see how we are able to test the `GroceryList` component without knowing any of its implementation details? This is what makes RTL so powerful. We can test our React components as if we are a real user and not worry about the specific logic that went behind coding them.

Don't worry if you cannot understand every single line of the code snippet above. In the upcoming exercises, you'll gain a strong understanding of React Testing Library and be able to do the following:
* Virtually render React components in the testing environment
* Use the `screen` object to query elements in the DOM to make assertions
* Utilize the `user-event` library extension to simulate user interactions in the DOM
* Understand the difference between query methods in React Testing Library
* Work with asynchronously rendered elements and understand the best practices to test them
* Verify the behavior of components that make API calls

What is React Testing Library?

Now that we know how to perform queries with `.getByX` methods, it is time for us to move on to the other query method variants. RTL has another category of query methods called `.queryByX`.

Look at the code below. It shows the code for a simple component that renders a header with the text `'Hello World!'` and then changes the text to `'Goodbye!'` 500ms after the user clicks a button. We will be using this `App` component to demonstrate the different query types.

```js
import { useState } from 'react';

const App = () => {

  const [text, setText] = useState('Hello World!');

  // Changes header text after interval of 500ms
  const handleClick = () => {
    setTimeout(() => {
        setText('Goodbye!');
    }, 500);
  };

  return (
    <div>
      <h1>{text}</h1>
      <button onClick={handleClick}>click me</button>
    </div>
  )
};

export default App;
```

Let's look at [`.queryByX`](https://testing-library.com/docs/queries/about/) variant. The `.queryByX` methods return `null` if they don't find a DOM node, unlike the `.getByX` methods, which throw an error and immediately cause the test to fail. This is useful when asserting that an element is NOT present in the DOM. 

In this example, we want to confirm that the `header` does not (yet) contain the text `'Goodbye'`:

```js
import App from './components/App';
import { render, screen } from '@testing-library/react';

it('Header should not show Goodbye yet', () => {
  // Render App
  render(<App />);
  // Attempt to extract the header element
  const header = screen.queryByText('Goodbye!');
  // Assert null as we have not clicked the button
  expect(header).toBeNull();
});
```

By using the `.queryByText()`, variant when there is no element with the text `'Goodbye!'`, the value `null` is returned, and we can successfully validate this with `expect(header).toBeNull()`. If the `.getByText()` method were used instead, the test would fail immediately due to the error rather than continuing on to the `expect()` assertion.

Different Query Methods

Now that we've covered a wide stretch of RTL methods, let's talk about accessibility and how it can help you write better tests. One of the guiding principles of React Testing Library is to write "queries that reflect the experience of visual/mouse users as well as those that use assistive technology." Usually, this means using the same text that the user would see, rather than the implementation details like class names or IDs. 

Writing tests that adhere to this principle forces you to make your applications more accessible. If a test can find and interact with your elements by their text, it's more likely that a user who uses assistive technology can as well.

One way we can write tests with accessibility concerns in mind is by sticking to querying with `ByRole` queries (`getByRole`, `findByRole`, `queryByRole`). The `ByRole` variant will be able to query any elements within the [accessibility tree](https://developer.mozilla.org/en-US/docs/Glossary/Accessibility_tree). If you are unable to query for the component you want to test, you may have just exposed a part of your application that is inaccessible. 

Let's see this in action. Suppose we're testing an input form:

```js
<input id="search" value="" />
```

If we try to use `getByRole`, it will not be able to query for this element. This exposes a component that is inaccessible. To fix it, we would have to make some modifications to the element by adding a `type` which provides a [role](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles) and `label` with an `htmlFor` attribute which provides an [accessible name](https://www.tpgi.com/what-is-an-accessible-name/) for an element. Note that how you assign accessible names differs based on the tag you're using.

```js
<label htmlFor="search">
   <input type="search" id="search" value="" />
</label>
```

Then our query can be:

```js
screen.getByRole('searchbox', {name: /search/i})
```

Great! We've knocked out two birds with one stone here. We made our input more accessible, and we were able to narrow down what query to use. 

While `ByRole` is a great default for accessibility, you can visit the [React Testing Library Playground](https://testing-playground.com) for suggestions on accessible queries for more complex needs. 

Including accessibility considerations in your testing process can help proactively identify and address potential accessibility issues. This not only ensures that your application is inclusive and usable by a wider range of users but also enhances the overall quality and user experience. 

> Note: If you want to explore a bit more about accessibility, check out the [What is Digital Accessbility](https://www.codecademy.com/article/what-is-digital-accessibility) article, or even try your hand at using [screen readers](https://www.codecademy.com/article/how-to-setup-screen-reader) to assess how accessible your projects are!

Testing for Accessibility

Good job! We can now use React Testing Library (RTL) to test our React components. Let's quickly review what we've learned so far:

- React Testing Library allows us to test React components by mimicking real user interactions.
- In order to make your component available in the unit test, we have to use the `render()` function. We can check to see the available components in our rendered DOM by using the `screen.debug()` method. `screen` is a special object that can be thought of as a representation of the browser window.
- RTL has built-in query methods (`.getByX`,`.findByX`,`.queryByX`) that allow us to extract the DOM nodes from your components. We can use these query methods by using the `screen` object, e.g., `screen.getByText()`.
- We can test the behavior of these extracted nodes by using the jest matchers provided by the `@testing-library/jest-dom` library. E.g. `expect().toBeChecked()`.
- We can mimic user interactions by using methods provided by the `testing-library/user-event` library. An example method is `userEvent.click()`.
- Besides `.findByX`, RTL has the `waitFor()` asynchronous function that can be used to test asynchronous events such as an element being removed asynchronously or a component making an API call.
- We can test with accessibility in mind by using `ByRole` query variants to help us discover accessibility holes in our applications.

Great job on your work thus far! You've learned a critical tool for thoroughly testing your application. Continue experimenting with what you've learned, and happy coding!