Convert all tests to a library that we agreed on and abandon others

Currently we are using Enzyme, react-testing-library and react-test-renderer to test behaviors of react components. Enzyme proved more useful for triggering events and manipulating the component. Also @julienw suggests that react-testing-library is built around the idea that we should test using the same things a user would use. Having 3 libraries is not a manageable situation and we should reduce it to one.

It’s also a pain when we try to upgrade the tests one by one. It would be great if we can do all at once. After the migration, we can abandon others.

[julienw]

Thanks @canaltinova. I spent some weeks writing tests using react-testing-library and I should try to explain why I think it would be valuable to use this library instead of enzyme. Teaser: it’s not just because dan abramov said so 😃

First, a bit of history

At the beginning we used react-test-renderer which is the test library that React publishes. It’s very simple, and allowed us to test how a component renders from a Redux state. But we can’t test user interactions because it doesn’t support events.

Then we used Enzyme especially for this. Enzyme is a library that makes it easy to change the props and/or the state of a component from the “outside” of the component, and then provides an API to easily and deeply find elements in the virtual DOM tree.

And then lately kentcdodds introduced react-testing-library, that aims to be very simple, especially compared to Enzyme, but still providing a useful API to fully test components on the contrary to react-test-renderer.

Enzyme’s caveats

Connected components

I think Enzyme doesn’t work well for connected components. Because of how enzyme v3 works (essentially it uses a layer) we need to call update whenever the redux store changes to actually “see” the changes in the enzyme-based test. This can be very cumbersome, eg: https://github.com/devtools-html/perf.html/blob/4c11b8ffb553950ddb8c859365b537ee55d5f864/src/test/components/CallTreeSidebar.test.js#L89-L107

Shallow rendering

This is a false good idea. We used it in the past for these components that are towards the Root of the application: if we’d render everything it would be too slow, and also give too much detail in our snapshots. But I now believe this was a bad idea. kentcdodds writes about it here. I’d like to add that the shallow API in Enzyme essentially replaces React. As a result we don’t test our component with React but with another imperfect library that may (and does!) behave differently. For example it’s not possible to get componentDidUpdate called if the props changed after a Redux store change.

Enormous API and library

The API is very big and it’s very difficult from the documentation to understand what we should use and what we shouldn’t. This could be worked around by some best practices on our end, but this is isn’t very easy. The library itself is big, so it’s difficult to look at its source code if we encounter a problem.

react-testing-library’s strengths

• the API is small and the library easy to look at in case of problems
• the API is centered around the idea that the test should behave like a user does: from the displayed text. I like that a lot.
• it works with DOM events on a real DOM (where enzyme uses simulate which isn’t exactly what a user does)
• it works directly on the DOM 😃 (so no need for update calls after dispatching actions)
• no shallow rendering => instead we can use mocks like https://github.com/devtools-html/perf.html/blob/4c11b8ffb553950ddb8c859365b537ee55d5f864/src/test/components/Root.test.js#L18-L24

For these reasons I believe this library is better suited to our project, that’s why I’m strongly in favor of switching to this library for all our tests. I’m willing to do this work after working on #1575 and I don’t think this is a lot of work as most of our tests are still simple for now.

[julienw]

I started here => https://github.com/devtools-html/perf.html/compare/master...julienw:migration-to-react-testing-library

As expected the migration from react-test-renderer is quite strightforward, but a bit more challenging from enzyme. No real roadblocks so far.