Comparing React testing libraries

Editor’s Note: This post was updated in October 2021 with relevant information.

If you create something, no matter what it is, you should test it before serving it to other people. This helps developers assess the stability of their projects. That way, you can have more confidence and control over your finished product before you roll it out.

React application testing strategies

There are several ways to test React applications, everything from little pieces of code blocks to more general aspects. Before we dive into the frameworks and libraries associated with them, let’s examine some of the most useful methods to evaluate the functionality of your React app.

What is unit testing?

A unit test examines each small piece of your code. You may think of it as testing primitive components in their life cycles. This is often the simplest and least expensive testing option. One example of a unit test can be to check whether a validation function (our unit) returns an expected output.

Integration tests

If you have many composed components, you may want to test how they interact with each other. You can do this by mocking your endpoints as part of an integration test. This can be costlier and more complex than unit testing.

Here, a common use case would be to analyze whether multiple units (for example, an authentication and a registration component in a shopping website) work together properly.

End-to-end testing

When it comes time to test the entire system with real data to see whether everything works as expected, end-to-end testing is your best bet.

One notorious use case for this type of test is when developers ensure that their application UI (the frontend) and their database (the backend) work properly with one other.

When you start writing your test, you may be tempted to tinker with your component’s internal business and test implementation details, which will lead you down the wrong path. Instead, you should write tests from the user’s perspective to generate cleaner and more accurate test cases. After all, your end users are not interested in your component’s internal details, but they are interested in what they see.

Now that we’ve established some general best practices, let’s take a closer look at some of the most common testing frameworks and runners. We’ll examine the learning curves, capabilities, and pros and cons associated with each.

Testing React apps with Jest

Jest is a testing framework created and maintained by Facebook. If you build your React application with Create React App, you can start using Jest with zero config. Just add react-test-renderer and the @testing-library/react library to conduct snapshot and DOM testing.

With Jest, you can:

• Conduct snapshot, parallelization, and async method tests
• Mock your functions, including third-party node_module libraries
• Execute myriad assertion methods
• View code coverage report

Now let’s get our hands dirty with some code.

Installing Jest for testing

Let’s assume your application is created via CRA:

# For snapshot test
yarn add -D react-test-renderer

# For DOM test
yarn add -D @testing-library/react

For an existing application that is not built with CRA, follow these steps:

1. Add dependencies

   yarn add --dev jest babel-jest @babel/preset-env 
   react-test-renderer

2. Configure Babel so that it uses your Node installation, like so:

   // create a file called babel.config.js in the root of your project:
   module.exports = {
   presets: presets: [['@babel/preset-env', {targets: {node: 'current'}}]]
   Add the testing command in your package.json.
   // package.json
   {
   "scripts": {
   "test": "jest"
   }
   

This will tell Yarn that every time you execute the yarn test command, Jest will run to perform tests on your web app.

---

Over 200k developers use LogRocket to create better digital experiences

Learn more →

---

Testing structure in Jest

Now that you’ve added test files to your application, let’s dive into some more details about the testing structure.

As shown below, CRA has been configured to run tests that have .spec.js and .test.js files.

// MyComponent
export const MyComponent = ({ label }) => {
  return <div>{label}</div>;
};

We have a simple component that takes a label prop and displays it on the screen. The next step is to write a small test to ensure that it displays properly.

import React from "react";
import { cleanup, render } from "@testing-library/react";
import { MyComponent } from "./MyComponent";

afterEach(cleanup);

describe("MyComponent", () => {
  test("should display label", () => {
    //next, get the value of MyComponent’s prop.
    const { getByText } = render(<MyComponent label="Test" />);
      //if MyComponent’s prop is ‘Test’, then consider this test as ‘passed’
    expect(getByText("Test")).toBeTruthy();
  });
});

Now let’s go over the features we want to test.

afterAll and beforeAll

The afterAll method will run code after the tests are completed in the current test file. On the other hand, beforeAll will run just before your test starts You can clean up your resources and mock data created on the database by using the afterAll function, or you can set up your configurations in beforeAll.

That function may return a generator or a promise, and it will wait for your promise or generator function to finish its execution before it continues. Here’s an example:

// MyTestFile.test.js
afterAll(() => {
  cleanResources(); //clean all render data. This will prevent memory leaks.
});

beforeAll(() => {
   setupMyConfig(); //example: set some global state so that it can be shared with multiple test files.
});

describe("MyComponent",() => {
   test("should do this..",() => {
      expect(prop).toBeTruthy();
   });
});

afterAll runs when all your tests finish their executions in the current file.

afterEach and beforeEach

Unlike afterAll and beforeAll, these functions are called for each test case in your test file. By using beforeEach, you can create a connection to your database before each test case starts to run. As a best practice, you should use afterAll to remove your created DOM elements after each test case run.

// MyTestFile.test.js
afterAll(() => {
  resetDomTree();
});

beforeAll(() => {
  createDomElement();
  connectToDB();
});

describe("MyComponent",() => {
   test("should do this..",() => {
      expect(prop).toBeTruthy();
   });
//create another test:
   test("should do that..",() => {
      expect(prop).toBeTruthy();
   });
});

describe

This command allows you to group related tests to produce cleaner outputs.

describe("MyComponent",() => {
   test("should do this..",() => {
      expect(prop).toBeTruthy();
   });

   test("should do that..",() => {
      expect(prop).toBeTruthy();
   });
});

Snapshot testing with Jest

A snapshot test generates an HTML-like output so you can see how your component is structured. It’s especially useful if you want to see the structure of your HTML or how your CSS properties are injected according to events.

import React from 'react';
import Link from '../Link.react';
import TestRenderer from 'react-test-renderer';

test('renders correctly', () => {
  const tree = TestRenderer
    .create(<Link page="http://www.mydomain.com">My Domain</Link>)
    .toJSON();
  expect(tree).toMatchSnapshot(); //make assertions on root.
});

// generated snapshot
exports[`renders correctly 1`] = `
<a
  className="normal"
  href="http://www.mydomain.com"
  onMouseEnter={[Function]}
  onMouseLeave={[Function]}
>
  My Domain
</a>
`;

Mocking functions

Mocking while testing is one of the core features you will need to implement. Jest is great for mocking not only your functions but also your modules.

For example, let’s say you want to test a function that fetches users. It uses Axios, but we don’t want to hit a real endpoint because that’s not what we want to test.

import axios from 'axios';
import { Customers } from "./customers";

jest.mock('axios');

test('should fetch users', () => {
  const customers = [{name: 'Bob'}, {name: 'Jenny'}];
  const resp = {data: customers.find(c => c.name = 'Bob')};
  axios.get.mockResolvedValue(resp);

  return Customers.getByFilter("Bob").then(data => expect(data).toEqual({name: 'Bob'}));
});

Testing with Jasmine

Like Jest, Jasmine is a JavaScript framework and test runner. However, you should add some configuration before you start using Jasmine.

Here are some neat things you can do with Jasmine:

• Async function tests
• Mocking requests
• Custom equality checker assertion
• Custom matcher assertion

As for drawbacks, below are some things Jasmine does not support:

• Snapshot tests
• Code coverage tools
• Parallelization (requires third-party tools)
• Native DOM manipulation (requires a third-party tool such as JSDOM)

In addition, Jasmine looks for only .spec.js files; you must edit its configuration to look for .test.js files, too.

Installing Jasmine

Jasmine is mostly used with Enzyme, so you will need to install it and make some configurations.

yarn add -D babel-cli \
            @babel/register \
            babel-preset-react-app \
            cross-env \
            enzyme \
            enzyme-adapter-react-16 \
            jasmine-enzyme \
            jsdom \
            jasmine

Initialize your project for Jasmine with the following command.

yarn run jasmine init

Now we’ll put some configuration files in a spec/helper folder. They will be for Babel, Enzyme, and JSDOM.

// babel.js
require('@babel/register');

// for typescript
require('@babel/register')({
    "extensions": [".js", ".jsx", ".ts", ".tsx"]
});


// enzyme.js or enzyme.ts 
// be sure your file extension is .ts if your project is a typescript project
import jasmineEnzyme from 'jasmine-enzyme';
import { configure } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

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

beforeEach(function() {
  jasmineEnzyme(); //before each test, setup our jasmine config.
});


// jsdom.js

import {JSDOM} from 'jsdom';

const dom = new JSDOM('<html><body></body></html>');
global.document = dom.window.document;
global.window = dom.window;
global.navigator = dom.window.navigator;

Lastly, edit the Jasmine configuration file to ensure that the Babel, Enzyme, and JSDOM configs are loaded correctly.

Now it’s time to move into spec/support/jasmine.json.

// the important part here is we should load babel first.

// for normal projects
"helpers": [
  "helpers/babel.js",
  "helpers/**/*.js"
],

// for typescript projects
"helpers": [
  "helpers/babel.js",
  "helpers/**/*.{js,ts}"
],

Let’s review how we write a test with Jasmine. We will also touch upon Enzyme.

Most of the helper functions, such as afterAll, beforeAll, afterEach, and beforeEach, are similar to Jest, so let’s dig into how to write a basic test for a React component to see its structure.

const Utils = React.addons.TestUtils;
let element;
beforeEach(() => {
  element = React.createElement(
      MyComponent,
      {
        label: 'Hello'
      });
});

afterEach(() => {
  element = null;
});

describe('MyComponent', function() {
  it('can render without error', function() {
    const component = Utils.renderIntoDocument(element);
    expect(component).not.toThrow();
  });
})

To run it, run the jasmine .spec.js command.

Custom matcher with Jasmine

In Jasmine, you can write custom matcher functions to reuse globally in each test spec. A custom matcher could come in handy if, for example, you have a specified group of testing matchers that are used frequently.

Custom matchers should return an object that has pass and message properties. A pass property checks that conditions are in a valid state. message is the field that is shown in a failed state.

const customMatchers = {
  toBeValidAgeRange: function() {
    return {
      compare: function(actual, expected) {
         var result = {};
         result.pass = (actual > 18 && actual <=35);
         result.message = actual + ' is not valid';   
         return result;
      }
    };
  }
};
describe("Custom matcher", function() {
  beforeEach(function() {
    // register our custom matcher with Jasmine
    jasmine.addMatchers(customMatchers);
  });
  it("should be valid age", function() {
    expect(19).toBeValidAgeRange();
  });

  it("should fail", function() {
    expect(38).toBeValidAgeRange();
  });
});

Custom equality checker

Sometimes, you may need to compare two objects or change the behavior of equality checking to compare primitive types. Jasmine has a good API for overriding equality checking.

Custom checker function must have two parameters: the first comes from expect and the second comes from the assertion function. Also, it must return boolean or undefined. If it returns undefined, that means the equality function is not suitable for these parameters.

function myObjectChecker(first, second) {
//check if they both are objects and have the ‘name’ field  
  if (typeof first === 'object' && typeof second === 'object' && 
      first.hasOwnProperty('name') && second.hasOwnProperty('name')) {
    return first.name === second.name;
  }
}

beforeEach(() => {
//now register your tester with Jasmine so that we can use it.  
jasmine.addCustomEqualityTester(myObjectChecker);
});

describe('MyComponent', function() {
  it('can render without error', function() {
    expect({name: 'John'}).toEqual({name:'John'}); //will pass the test
  });
  it('Not equal using a custom tester.', function() {
    expect({name: 'John'}).not.toEqual({age:19}); //will pass the test.
  });
});

Using react-testing-library to test React applications

Created by Kent C. Dodds and maintained by a huge community of developers, this library enables you to test components without touching their internal business — which in turn empowers you to conduct more powerful test cases while keeping the user experience top of mind.

With react-testing-library, you can:

• Query your elements within tthe text, label, displayValue, role, and testId
• Fire any event
• Wait for an element to appear with wait

However, you cannot:

• Conduct shallow rendering
• Access internal business of your components, such as states

Installation

yarn add -D @testing-library/react

Now for the fun part…

import React from 'react';
import { render, RenderOptions, RenderResult, fireEvent, screen} from '@testing-library/react';

describe('MyComponent', () => {
  test('Click on item', () => {
    
    render() //render the component to the DOM
    fireEvent.click(screen.getByText(“Click me”)); //find the button and click it.
    expect(screen.getByRole(‘button’)).toBeDisabled() //if the button is disabled, pass the test.
  });
}

(API documentation)

Testing React components with Enzyme

Enzyme is a JavaScript testing utility framework designed to help developers test React components easily. It’s maintained by Airbnb and is among the most used frameworks.

Enzyme enables you to:

• Use shallow rendering
• Access business implementations of your components
• Conduct full DOM rendering
• Use react-hooks in shallow rendering, with some limitations

Here’s a handy guide if you want to compare Enzyme to react-testing-library in-depth.

Installing Enzyme

yarn add -D enzyme enzyme-adapter-react-16

Create an enzyme.js in src folder, as shown below.

import Enzyme, { configure, shallow, mount, render } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

configure({ adapter: new Adapter() });
export { shallow, mount, render };
export default Enzyme;

Now let’s do some coding.

Shallow rendering

import React from 'react';
// we are importing from our enzyme.js
import { shallow } from './enzyme';

import MyComponent from './MyComponent';

describe('MyComponent', () => {
  test('renders correct text in item', () => {
    const wrapper = shallow(<MyComponent label="Hello" />);

    //Expect the child of the first item to be an array
    expect(wrapper.find('.my-label').get(0).props.children).toEqual('Hello');
  });
});

Full DOM rendering

describe('<Foo />', () => {
  it('calls componentDidMount', () => {
    sinon.spy(Foo.prototype, 'componentDidMount');
    const wrapper = mount(<Foo />);
    expect(Foo.prototype.componentDidMount).to.have.property('callCount', 1);
  });
}

Beware of componentDidMount! We accessed the internal business of our component, which may lead you to write incorrect test cases if you’re not careful.

Performing end-to-end tests in React apps

Up to this point, we’ve examined testing libraries in terms of writing unit or integration tests. However, we may also need a fully integrated test with the backend before going to production. For that purpose, we will look to two libraries: Cypress and Puppeteer.

Cypress

Cypress enables you to write your tests without any additional testing framework. It has a nice API to interact with page components, and it supports many browsers, including Firefox and other Chrome-based browsers.

What you can do:

• Time travel
• Screenshots and videos
• Automatic waiting
• Control network traffic without touching your server to test edge cases
• Parallelization

Use the following lines of code to install and run Cypress, respectively.

yarn add -D cypress
yarn run cypress open

Now let’s write some tests.

First, create a file named my-test_spec.js.

describe('My First Test', function() { //first, describe your test
  it('Gets, types and asserts', function() {
    cy.visit('https://www.mydomain.com') //visit your app. Can be localhost.
    cy.contains('login').click() //find the button that contains ‘login’

    cy.url().should('include', '/login')

    cy.get('.email') //find textbox with class ‘email’. Cypress uses JQuery selectors.
      .type('[email protected]')
      .should('have.value', '[email protected]')
  })
})

Puppeteer

Puppeteer is not a JavaScript testing framework — it’s a headless Chromium library mostly used for automation purposes. You can start your Chromium and, with the provided API, navigate between pages, get buttons, and click on them.

Puppeteer runs on a real browser and enables you to write your end-to-end tests with an API similar to the browser.

To install, enter the following line of code.

yarn add -D jest-puppeteer puppeteer jest

Then enter the following in package.json.

// package.json
{
 jest: {
    "preset": "jest-puppeteer"
  }
}

Below is the code for our e2e testing.

beforeAll(async ()=> {
  await page.goTo('http://mydomain.com');
});

describe('Visit MyDomain', () => {
  test('should have login text', () => {
     await expect(page).toMatch('login');
  });
});

Comparing React testing libraries and frameworks head-to-head

Until now, we looked at features of libraries and how to implement them in our projects. Now, let’s examine some benchmarks and compare the results among libraries.

Jest versus Jasmine

As we mentioned in the beginning, Jest and Jasmine are used as testing frameworks. You group your test cases within describe blocks and write your tests within test or it functions.

Now let’s break down our comparison in a handy, easy-to-read table.

Here’s what I like most about Jest:

• Zero configuration required
• Snapshot testing support
• Code coverage support
• Mocking functions

As for Jasmine, the most useful feature is its mocking function. Though this is somewhat limited, it is sufficient for most use cases.

I am currently using Jest in a product due to its native support within the React community, and because it serves our needs in terms of testing React components more so than Jasmine.

react-testing-library vs. Enzyme

Among the most important considerations when writing tests for a component are your util functions. They may force you to write a cleaner and truer way of testing or lead you to write your tests incorrectly in terms of exported APIs.

When writing tests for your components, don’t get too bogged down in the implementation details. Remember, try to think about it from the user’s perspective. This will help you produce better test suites, which will help you feel more confident about your tests.

For most use cases, I prefer react-testing-library, primarily because its exported APIs do not allow you to use a component’s internal API, which forces you to write better tests. In addition, there is zero configuration required.

Enzyme, on the other hand, lets you use a component’s internal API, which can include life cycle methods or state.

I’ve used both Enzyme and react-testing-libraries in many projects. However, I’ve often found that react-testing-library makes things easier.

Cypress vs. Puppeteer

Testing your critical pages end to end may save your life before going to production. Below is a summary comparison of Cypress and Puppeteer.

Because Cypress is a testing framework, it has many advantages over Puppeteer when the things you want to develop need to be fast.

Its APIs are developer-friendly and it enables you to write a test like you would write a unit test. Puppeteer is not a testing framework but a browser. Its APIs are not developer-friendly, but they are powerful because you can access the browser’s API. Thus, it comes with a steeper learning curve than Cypress.

Conclusion

As you can see, each testing method, library, and framework brings its own advantages and shortfalls, depending on the use case and types of data you wish to analyze.

After evaluating each testing framework with these factors in mind, it’s clear that react-testing-library is the most valuable and logical choice for unit and integration tests. For end-to-end testing, Cypress is an appropriate choice for its easy-to-learn API.

LogRocket: Full visibility into your production React apps

Debugging React applications can be difficult, especially when users experience issues that are hard to reproduce. If you’re interested in monitoring and tracking Redux state, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, try LogRocket.

LogRocket combines session replay, product analytics, and error tracking – empowering software teams to create the ideal web and mobile product experience. What does that mean for you?

Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay problems as if they happened in your own browser to quickly understand what went wrong.

No more noisy alerting. Smart error tracking lets you triage and categorize issues, then learns from this. Get notified of impactful user issues, not false positives. Less alerts, way more useful signal.

The LogRocket Redux middleware package adds an extra layer of visibility into your user sessions. LogRocket logs all actions and state from your Redux stores.

Modernize how you debug your React apps — start monitoring for free.