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:
- Add dependencies
yarn add --dev jest babel-jest @babel/preset-env react-test-renderer
- 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.
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
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
, andtestId
- 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. }); }
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.
How come Cypress gets four stars for browser support when it only works in Chrome? The entire post is flawed but this has really triggered me.
It’s not exactly fair to call the entire post flawed without an explanation.
Hi Milos,
Thanks for your comment. But there is not any technical problem in document. Cypress supports Canary, Chrome, Chromium and Electron, so got 4 star while puppeteer only supports chromium and gets one star. In addition to that, cypress has roadmap (https://github.com/cypress-io/cypress/issues/3207) for supporting firefox and ie11, also that feature will make it even stronger in near future so it deserves 4 star for me.
Reference document https://docs.cypress.io/guides/guides/launching-browsers.html#Browsers
Also, that document is created by prior experiences plus current documents of libraries. You may not be with same idea about authors’ personal comments (about that given stars…), but it is not right you to call whole work as useless and flawed.
For end to end, @DXTestCafe should have been considered. Apart from awesome ES6 support, we can test on different browsers while Cypress and Puppeteer are Chrome browser constrained as of now.
Hi Murat,
Can I ask your opinion on React component testing with Cypress + https://github.com/bahmutov/cypress-react-unit-test? Your feedback would be super useful to guide further development
I am not sure it is! could you elaborate more on why you think the post is flawed?
Also Cypress supports a wide range of browsers including Edge, Firefox and Electron (including unstable channels like dev and canary to test against future releases), the only reason that triggered you is actually not true.
There is also a Safari Support request that is currently being evaluated: https://github.com/cypress-io/cypress/issues/6422.