How to use React Testing Library to rewrite an Enzyme Component test

A mini-rewrite case study of two testing libraries

Luke Ghenco
Jan 16, 2019 · 7 min read
The Dream of 100% Test Coverage

Learnings from a recent conversion

At Flatiron School, we have been adding a ton of new test coverage using Kent Dodd’s React Testing Library. Check out my other blog posts on React testing (Creating Readable Tests Using React Testing Library & Testing Async React Hooks)for some awesome tips on using the tool (I know, I know! That was a shameless plug). As we’ve been improving our overall front end (FE) test coverage, there have been certain React components using Enzyme tests that needed some attention.

Quick Setup Info

This is using code that has been slightly modified and simplified from our code base. To get this running locally, copy the code over to a simple Create React App and add the React Testing Library.

The Component(s) we are testing

The core component we will be testing is for a textarea input that uses a secondary child component to render an error message. Here is what the code looks like:

Step: 1

The original Enzyme test

This is what our current tests look like:

Step: 2
  1. The code coverage for TextAreaInput.jsx is currently 90% on statements and 62.5% for branches.
  2. The code coverage for required InputError.jsx is currently 42.86% on statements and 0% for branches.
  3. The overall code coverage for both components is currently 72.2% on statements and 50% for branches.

{mount, shallow} vs render

With Enzyme we have the concepts of Mount and Shallow for rendering component. This is a really good Gist on the differences: Difference between Shallow, Mount and render of Enzyme. Basic answer: Mount renders everything and allows all lifecycle methods to be used & Shallow only renders the component with limited functionality and no child components. This allows for basic unit testing, but the UI never really works independently of itself, so we’ve found that we get brittle test coverage when we used Shallow in the past.

Looking for similar test patterns

So the first thing I like to do is try to find testing strategies that work in Enzyme and React Testing Library (i.e. Integration Testing or as a user would interact with the component).

Step: 3
Step: 4
Step: 5
  1. The code coverage for TextAreaInput.jsx is now at 90% (no difference) on statements coverage and 70% (+7.5% improvement) for branch coverage.
  2. The code coverage for required InputError.jsx is now at 100% (+57.14% improvement) on statements coverage and 100% (+100% improvement) for branch coverage.
  3. The overall code coverage for both components is now at 94.4% (+22.2% improvement) on statements coverage and 80% (+30% improvement) for branch coverage.

Looking for test paths that we didn’t cover in Enzyme

That was an incredible improvement in readability, simplicity, and code coverage all with less lines of code. Now let’s focus on improving our test coverage to 100% and testing out all of the branching paths that are component handles.

  1. How does it connect label tag to textarea tag if id prop is not present?
  2. How does it disable the textarea tag?
  3. How does it handle placeholder text?
  4. Will it render the value prop inside of the textarea tag?
Step: 6
Step: 7
Step: 8
Step: 9
Step: 10
Step: 11
Step: 12

Checking out the final code coverage using the new tests

So now that we’ve completed our new test code, it should look like this:

Step: 13 — Final

Closing Thoughts

We’ve found great success so far in improving our overall code coverage on our FE code in the last few months since switching over to React Testing Library and I can not recommend it enough. The ease of use in adding tests to new components and converting old tests to use React Testing Library can not be overstated.

Footer top
Footer bottom

Flatiron Labs

We're the technology team at The Flatiron School (a WeWork…