Test React components with React Testing Library.

React Testing Library

In the previous exercise we've learned about the `.findByX` query methods that allows 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
// file: 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 for 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'

test('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

Now that we know how to set up RTL, we can finally start testing our React components. 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>
};

test('A "Submit" button is rendered', () => {
  // Render the Button component
  render(<Button/>);
  // Extract the <button>Submit</button> node
  const button = screen.getByText('Submit'); 
});
```

Similarly, another method is `.getByRole()` that 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>
};

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

You can install this library using the command `npm install --save-dev @testing-library/jest-dom`. 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>
};

test('should show 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 just follow the [`jest-dom` docs](https://github.com/testing-library/jest-dom). 

Querying with RTL

In order to use React Testing Library, we will need to include the `@testing-library/react` package in our project by using `npm` like so:

```sh
npm install @testing-library/react --save-dev
```

Once we have added `@testing-library/react` to our project, we can import the two essential values, `render` and `screen`, into our tests. 
* `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>)
};

test('should 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 `test()` 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!


Setting up React Testing Library

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 e.g. clicking a checkbox, typing text, etc. 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`.

The library can be installed with the command below:

```sh
npm install --save-dev @testing-library/user-event@12.0.4
```

> Note: There is a [known issue](https://github.com/testing-library/user-event/issues/369#issuecomment-647124402) with the `userEvent.type()` method that was resolved in issue 12.0.4. To avoid this issue, install version 12.0.4 of the package.

This library exports a single object, `userEvent`, that can 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>
  );
};

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

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

test('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, we will cover RTL so that you can understand everything that's going on.

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 two other categories of query methods called `.queryByX` and `.findByX`.

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 start with the [`.queryByX`](https://testing-library.com/docs/queries/about/) variants. 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';

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

Next, let's discuss the [`.findByX`](https://testing-library.com/docs/queries/about/) variants. The `.findByX` methods are used to query for asynchronous elements which will eventually appear in the DOM. For example, if the user is waiting for the result of an API call to resolve before data is displayed. 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.

In this example, we want to confirm that the `header` will display the text `'Goodbye'` after the button is clicked. 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';

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

Different Query Methods

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

Want to learn more about testing your React components? Check out the article(s) below!
* [Testing Implementation Details](https://kentcdodds.com/blog/testing-implementation-details)