Testing code is a confusing practice for many developers. That's understandable because writing tests requires more effort, time, and the ability to foresee possible use cases. Startups and developers working on smaller projects usually favor ignoring tests altogether because of the lack of resources and manpower. 

However, there are a couple of reasons why I believe that you should test your components:

1. It makes you feel more confident about your code.
2. Tests enhance your productivity.

React isn't any different either. When your whole application starts to turn into a pile of components that are hard to maintain, testing offers stability and consistency. Writing tests from day one will help you write better code, spot bugs with ease, and maintain a better development workflow. 

In this article, I will take you through everything that you need to know to write tests for your React components. I'll also cover some of the best practices and techniques while we're at it. Let's get started!

Testing Components in React

Testing is the process of verifying that our test assertions are true and that they stay true throughout the lifetime of the application. A test assertion is a boolean expression that returns true unless there is a bug in your code. 

For instance, an assertion could be something as simple as this: "When the user navigates to /login, a modal with the id #login should be rendered." So, if it turns out that you messed up the login component somehow, the assertion would return false. Assertions are not just limited to what gets rendered—you can also make assertions about how the application responds to user interactions and other actions. 

There are many automated testing strategies that front-end developers use to test their code. We will limit our discussion to just three software test paradigms that are popular with React: unit testing, functional testing, and integration testing.

Unit Testing

Unit testing is one of the test veterans that's still popular in testing circles. As the name suggests, you will be testing individual pieces of code to verify that they function independently as expected. Because of React's component architecture, unit tests are a natural fit. They're also faster because you don't have to rely on a browser.

Unit tests help you think of each component in isolation and treat them as functions. Your unit tests for a particular component should answer the following questions:

1. Are there any props? If yes, what does it do with them?
2. What components does it render? 
3. Should it have a state? When or how should it update the state?
4. Is there a procedure that it should follow when it mounts or unmounts, or on user interaction?

Functional Testing

Functional tests are used to test the behavior of a part of your application. Functional tests are usually written from a user's perspective. A piece of functionality is usually not limited to a single component. It can be a full-fledged form or an entire page. 

For instance, when you're building a signup form, it might involve components for the form elements, the alerts, and errors if any. The component that gets rendered after the form is submitted is also part of that functionality. This doesn't require a browser renderer because we'll be using an in-memory virtual DOM for our tests.

Integration Testing

Integration testing is a test strategy where all the individual components are tested as a group. Integrated testing attempts to replicate the user experience by running the tests on an actual browser. This is considerably slower than functional testing and unit tests because each test suite is executed on a live browser. 

In React, unit tests and functional tests are more popular than integration tests because they are easier to write and maintain. That's what we will cover in this tutorial.

Know Your Tools 

You need certain tools and dependencies to get started with unit and functional testing your React application. I've listed them below.

Jest Test Framework

Jest is a testing framework that requires zero configuration and is therefore easy to set up. It's more popular than test frameworks like Jasmine and Mocha because it's developed by Facebook. Jest is also faster than the rest because it uses a clever technique to parallelize test runs across workers. Apart from that, each test runs in a sandbox environment so as to avoid conflicts between two successive tests. 

If you're using create-react-app, it comes shipped with Jest. If not, you might have to install Jest and a few other dependencies. You can read more about it on the official Jest documentation page. 

react-test-renderer

Even if you're using create-react-app, you will need to install this package to render snapshots. Snapshot testing is a part of the Jest library. So, instead of rendering the UI of the entire application, you can use the test renderer to quickly generate a serializable HTML output from the virtual DOM. You can install it as follows:

yarn add react-test-renderer

ReactTestUtils and Enzyme

react-dom/test-utils consists of some of the test utilities provided by the React team. Alternatively, you can use the Enzyme package released by Airbnb. Enzyme is a whole lot better than ReactTestUtils because it is easy to assert, manipulate, and traverse your React Components’ output. We will start our tests with React utils and then transition to Enzyme later on.

To install Enzyme, run the following command.

yarn add enzyme enzyme-adapter-react-16

Add the code to src/SetupTests.js.

import { configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

configure({ adapter: new Adapter() });

There is more information about this in the Testing Components section of the create-react-app page. 

Setting Up a Demo App and Organizing Tests

We will be writing tests for a simple demo application that displays a master/detail view of a list of products. You can find the demo application in our GitHub repo. The application consists of a container component known as ProductContainer and three presentational components: ProductList, ProductDetails, and ProductHeader. 

Directory Structure

.
├── package-lock.json
├── package.json
├── public
│   ├── index.html
│   └── manifest.json
├── src
│   ├── components
│   │   ├── App.js
│   │   ├── ProductContainer.js
│   │   ├── ProductDetails.jsx
│   │   ├── ProductHeader.js
│   │   ├── ProductList.jsx
│   ├── index.js
│   └── style.css

This demo is a good candidate for unit testing and functional testing. You can test each component in isolation and/or test the product listing functionality as a whole. 

Once you've downloaded the demo, create a directory with the name __tests__ inside /src/components/. You can then store all the test files related to this functionality inside the __tests__ directory. Testers usually name their test files as either .spec.js or .test.js—for example, ProductHeader.test.js or ProductHeader.spec.js. 

Writing Basic Tests in React

Create a ProductHeader.test.js file if you haven't already. Here is what our tests are basically going to look like:

src/components/__tests__/ProductList.test.js

describe('ProductHeader', () => {

  it('passing test', () => {
    expect(true).toBeTruthy();
  })

  it('failing test', () => {
    expect(false).toBeTruthy();
  })
})

The test suite starts with a describe block, which is a global Jest function that accepts two parameters. The first parameter is the title of the test suite, and the second parameter is the actual implementation. Each it() in a test suite corresponds to a test or a spec. A test contains one or more expectations that check the state of the code. 

expects(true).toBeTruthy();

In Jest, an expectation is an assertion that either returns true or false. When all the assertions in a spec are true, it is said to pass. Otherwise, the test is said to fail.

For instance, we've created two test specs. The first one should obviously pass, and the second one should fail. 

Note: toBeTruthy() is a predefined matcher. In Jest, each matcher makes a comparison between the expected value and the actual value and returns a boolean. There are many more matchers available, and we will have a look at them in a moment.

Running the Test Suite

create-react-app has set up everything that you need to execute the test suite. All you need to do is run the following command:

yarn test

You should see something like this:

To make the failing test pass, you have to replace the toBeTruthy() matcher with toBeFalsy().

expects(false).toBeFalsy();

That's it!

Using Matchers in Jest

As mentioned earlier, Jest uses matchers to compare values. You can use it to check equality, compare two numbers or strings, and verify the truthiness of expressions. Here is the list of popular matchers available in Jest. 

• toBe();
• toBeNull()
• toBeDefined()
• toBeUndefined()
• toBeTruthy()
• toBeFalsy()
• toBeGreaterThan()
  
• toBeLesserThan()
• toMatch()
• toContain()

This is just a taste. You can find all the available matchers in the reference docs.

Testing a React Component

First, we'll be writing a couple of tests for the ProductHeader component. Open up the ProductHeader.js file if you haven't already. 

src/components/ProductHeader.js

import React, {Component} from 'react';

class ProductHeader extends Component  {
    render() {
        return(
            <h2 className="title"> Product Listing Page </h2>
        );
    }
};
export default ProductHeader;

Are you curious to know why I used a class component here instead of a functional component? The reason is that it's harder to test functional components with ReactTestUtils. If you're curious to know why, this Stack Overflow discussion has the answer.

We could write a test with the following assumptions:

1. The component should render an h2 tag.
2. The h2 tag should have a class named title.

To render a component and to retrieve relevant DOM nodes, we need ReactTestUtils. Remove the dummy specs and add the following code:

src/components/__tests__/ProductHeader.test.js

import React from 'react';
import ReactTestUtils from 'react-dom/test-utils';
import ProductsList from '../ProductsList';

describe('ProductHeader Component', () => {

    it('has an h2 tag', () => {
     //Test here
    });

    it('is wrapped inside a title class', () => {
     //Test here
    })
  })

To check for the existence of an h2 node, we will first need to render our React elements into a DOM node in the document. You can do that with the help of some of the APIs exported by ReactTestUtils. For instance, to render our <ProductHeader/> component, you can do something like this:

 const component = ReactTestUtils.renderIntoDocument(<ProductHeader/>);    

Then, you can extract the h2 tag from the component with the help of findRenderedDOMComponentWithTag('tag-name'). It checks all the child nodes and finds the node that matches the tag-name. 

Here is the whole test spec.

    it('has an h2 tag', () => {

      const component = ReactTestUtils.renderIntoDocument(<ProductHeader/>);
      var h2 = ReactTestUtils.findRenderedDOMComponentWithTag(
       component, 'h2'
     );

  });

Try saving it, and your test runner should show you that the test has passed. That's somewhat surprising because we don't have an expect() statement like in our previous example. Most of the methods exported by ReactTestUtils have expectations built into them. In this particular case, if the test utility fails to find the h2 tag, it will throw an error and the tests will automatically fail.

Now, try creating the code for the second test. You can use findRenderedDOMcomponentWithClass() to check if there's any node with the class 'title'.

    it('has a title class', () => {

      const component = ReactTestUtils.renderIntoDocument(<ProductHeader/>);
      var node = ReactTestUtils.findRenderedDOMComponentWithClass(
       component, 'title'
     );
    })

That's it! If all goes well, you should see the results in green. 

Conclusion

Although we just wrote two test specs, we've covered a lot of ground in the process. In the next article, we'll write some full-fledged tests for our product listing page. We'll also replace ReactTestUtils with Enzyme. Why? Enzyme offers a high-level interface that's very easy to use and developer-friendly. Stay tuned for the second part!

If at any point you feel stuck or need help, let us know in the comments.