Resolve React errors faster with Zipy. Use advanced devtools and AI assistance.
Try for free
Testing computer programs, especially ones written using React, can be tricky. However, opting for a React testing library can save you a lot of hassle. Enzyme and React-testing-library are two popular options out there.
And in this article, we will look in how React-testing-library and Enzyme stack against each other and even run some tests together. The idea is to help you test out these libraries before you deploy your React app.
Released in 2018, the React Testing Library gained popularity quickly and is built on top of the DOM Testing Library. This testing library enables developers to write test cases for real events, such as a user clicking on a button, making it equivalent to actual user interaction. Later in this post, we will also demonstrate some test cases using the React Testing Library.
When it comes to testing React components, developers are increasingly adopting a different mindset. The objective of software testing a feature or a product before it goes to market is to identify and report any issues in the application, and be confident about the release.
In terms of testing structure, the difference between Enzyme and react-testing-library is quite apparent. With react-testing-library, it is easy to write tests that accurately represent how the application is experienced by users. When writing tests with react-testing-library, you're testing the application as if you are the user who is interacting with the app.
On the other hand, writing tests with Enzyme, while still achieving the same level of confidence as react-testing-library, can be a bit more challenging. This is because it can be more difficult to create a test structure that closely resembles how a real user would interact with the application.
In addition to the main diffrences between functional and class components in React, there are several other details that may influence your choice of tool for your next project. To illustrate this, I have developed a simple component idea using both approaches, which will also allow us to compare the test structures for each type of component.
The component we will create is called RangeCounter. It will have two control buttons for adding and subtracting, as well as a display of the current count between these buttons. The count will be determined by the props passed to the component, specifically the minimum and maximum values.
When the user reaches either the minimum or maximum value, they will receive an alert message indicating why they are unable to continue incrementing or decrementing the counter.
If you are interested in seeing the complete code, including tests, a GitHub repository is available for you to use alongside this post.
For both the class and functional components, we will conduct the following tests using each of these testing tools:
Let’s have a look at the first scenario using Enzyme.
This code is a test case for the RangeCounterClass component using the Enzyme testing library. It tests whether the counter value updates correctly when incrementing is allowed. It sets up a test suite with a describe block for the RangeCounterClass component and a beforeEach block to create a shallow wrapper of the component before each test. Then, there is a describe block for the scenario where incrementing is allowed, and it block that calls the incrementCounter method of the component instance and checks that the state of counter and hasEdited have been updated as expected using the expect function.
The test code ensures that the component works correctly by checking the received props and the component's state. If the test passes, it is assumed that the displayed count is the same as the counter-state variable. The test also verifies whether the hasEdited variable has changed to true after programmatically updating the counter, which indicates whether the alert should be displayed or not.
Now let’s try the same test scenario but now let us use the react-testing-library:
The above code block is an example of a test written using react-testing-library. It tests the RangeCounterB functional component to see if the counter value updates correctly when incrementing is allowed.
First, it renders the component with a minimum value of 2. Then it gets the increment button using getByText and simulates a click on it using fireEvent.click. Finally, it checks if the counter value has updated to 3 using getByTestId and expect.
The purpose of this test is to verify the user interface display, which is achieved by retrieving the actual DOM element and checking its content. The following three scenarios in the list use a similar approach. The last scenario, however, is particularly noteworthy as it shows that Enzyme can be used to test the same concept as react-testing-library.
The code block shows a test suite using Enzyme's shallow rendering method to test a component called RangeCounterClass. The beforeEach function is used to initialize the component before each test case.
The it function describes the behaviour being tested, which is if the component displays an alert message when the range limit is reached by clicking the control buttons. The component is re-initialized with specific props to simulate the range limit.
The test checks if the alert message is rendered with the correct text by finding the element with the .RangeCounter__alert class and comparing its text content with the expected value using the toEqual matcher.
This code is a test case using react-testing-library to check if the "Range limit reached!" alert message has shown up when the user has reached the max limit by clicking the increment button. It renders the RangeCounterB component with min and max props and gets the increment button by text. Then, it clicks the button and asserts that the alert message is visible.
Both Enzyme and react-testing-library confirm that the alert is displayed on the page, but they do it differently.
Enzyme commonly searches for elements in the page by their class, even though users don't see that information in the UI. After having the element, Enzyme checks its contents to ensure that it's what the user sees.
On the other hand, react-testing-library searches directly by the actual text that the user sees. If you have many child components and a more complex HTML structure, using Enzyme may pose more challenges when following the same concept.
If you're wondering if you can migrate your tests from one tool to the other, it's possible, but it may require some adjustments.
It is relatively simpler to migrate from Enzyme to react-testing-library as compared to the reverse. The strategy is to start using both of these libraries in your React app, and then one by one convert your Enzyme tests to RTL tests. Once this is done, you can remove all your Enzyme dependencies and stick to React Testing Library for future.
To switch from react-testing-library to Enzyme, you'll need to add an extra library called enzyme-adapter-react-[react-version]. This adapter library is essential, and its setup steps vary depending on your React version. Enzyme's adapters currently support up to React v.16, and there's an unofficial adapter for React v.17. Unfortunately, there's no adapter for React v.18 as of now.
After installing the adapter, you can choose your preferred test runner as Enzyme. Now you can start modifying your tests in RTL to run in Enzyme.
Determining whether React-testing-library or Enzyme is better depends on various factors. Here is a brief React-testing-library vs Enzyme comparison.
In conclusion, whether you have built your app from scratch or are using Bootstrap in React, both Enzyme and React-testing-library can be good options to explore. However chosing a React Testing Library ultimately depends on the specific needs of your project.
React-testing-library is better suited for testing user behaviour, while Enzyme may be better for matching the state of React or other functions with the state. Both tools have their limitations and benefits, and it's important to consider which tool will provide the most effective testing for your particular use case.