Testing React: A Convert’s Journey from Enzyme to Testing Library

Thank you for coming to this talk where I'm going to talk about why I switched from Enzyme to REACT Testing Library when it comes to testing REACT. So Enzyme and REACT testing library, they do the same job. Basically, if you're running unit and integration tests without a browser, you need a virtual DOM. You need a DOM so that you can interact with your app and so that you can test your app's behavior, which is the point of testing after all.

Here's a very brief timeline. In 2016, Enzyme was first released by Airbnb, and then in 2018, REACT testing library was first released by Kent C. Dots. This just gives you a backdrop to know that when I started testing REACT in 2016, I used Enzyme because testing library didn't exist. Enzyme also fit very well with my mode of testing. I liked to have very meticulous testing, a lot of unit testing that was really isolated, using a lot of mocks, and because it was isolated, I needed to test implementation details like state.

Fast forward to 2020, and a lot has changed, including the fact that React testing best practices have become better defined, and testing library, which helps define and enforce those best practices is very popular. At first I was pretty resistant to testing library. My approach to testing was under threat, I did not want someone else telling me how to do my tests. But it became clear that testing library wasn't going anywhere. So I decided to give it a try. It turns out that I am a total convert. So I'm going to give you some of the reasons why I now prefer testing library.

Testing library is famously opinionated, meaning that it encourages best practices by making it easy to do the right thing and hard to do the wrong thing. Best practices include interacting with your app the way users would and testing behavior. So basically your tests take user-style input and test user-style output, which makes it more likely that your tests will succeed when user behavior is correct and fail when user behavior isn't. As an offshoot of that, your tests are not going to need to be rewritten when you refactor your code. And by refactoring, I mean you change how your code is written, but you don't change the behavior.

So, React is constantly evolving. Recently, there's been a shift from class-based components to functional components and your app will evolve with React, but as long as the behavior isn't changing, your tests don't need updating. Another best practice encouraged by React testing library is accessible code. They recommend finding items the same way screen readers or other assistive technologies would. My code has become so much more accessible since I've started using testing library, I've just become a lot more aware of accessibility. It's possible in Enzyme to find elements based on accessibility handles, but it's much more difficult. Now, I would like to talk about two libraries in the testing library ecosystem that really improve your code, and so, I want to show you some contrast between how the code would look in Enzyme and how it looks in testing library. The first library is user event, and this is for interactions.

So, let's take an example where as part of your test, you need to type input into a text input. In Enzyme, your code would look like this. You would be simulating a change, and the change is that you would be changing the target value. This is not terribly readable, and it doesn't mimic how users interact. Users don't send change events.

Testing library with user event, on the other hand, is much more readable. You are typing hello world into your element. This also has options where you can simulate user behavior even more in a more detailed way. Using typing delays, clicking the element before typing, and so forth. So, big improvement here.

Just DOM assertions also improve upon the assertions that you can use in Enzyme. And for this, I'm going to use the example of asserting that an element is no longer visible after some user interaction. In Enzyme, you can expect that your property style will have visibility hidden, so this is also kind of cumbersome code wise, and it doesn't even cover all of the possibilities. There are lots of other reasons your element might not be visible, like display and opacity. With just DOM, you have this beautiful, succinct, expect my element not to be visible. So, it's more readable. And it also checks for all of the reasons that your code, excuse me, that your element might not be showing up on the page.

So, in conclusion, these are the reasons that I have come to prefer Testing Library. It is opinionated which makes it easy to follow best practices. It encourages accessible code to make sure that your tests can find elements in the same way assistive technologies can. And the code is just better. It is more readable and it simulates more how users actually interact. User event is very helpful for interactions, and JustDOM is helpful for assertions.