I recently developed an open source tool called MockIt that allows developers to mock endpoints. The interface with built with React and was tested with react-testing-library rather than my default testing library of choice Enzyme.
I have been using React and Enzyme together for years and I have have had some great experience using it to test React applications. More recently I have seen react-testing-library (developed by Kent C. Dodds) get more coverage and traction which intrigued me.
As part of MockIt I wanted to explore react-testing-library and understand the differences between it and Enzyme.
In this blog post, I will share with you my thoughts moving from Enzyme onto react-testing-library, what I experienced and why I would recommend react-testing-library going forwards.
Hopefully, this post can help you understand some key differences between the two libraries and inspire you to explore them for yourself.
So grab a drink, let’s get started 👍.
Why I had to use react-testing-library…
When building MockIt I wanted to use React Hooks which at the time limited me to what testing library I could use (Enzyme did not support them, and unsure if they do yet). So my other option was to use react-testing-library (which Facebook even recommends themselves).
react-testing-library tends to support new features of React out the box which for me was a huge benefit when testing Hooks.
I’m not sure if I could have got Enzyme to work with Hooks but I personally didn’t want to lose any more time trying in this project.
The biggest challenge I faced when moving from Enzyme to react-testing-library was the required mindset change when writing tests.
Mindset change from Enzyme to react-testing-library
If you are moving from Enzyme to react-testing-library I recommend having an open mind and be willing to think about your tests differently:
Rather than tests focusing on the implementation (Enzyme), tests are more focused on user behavior (react-testing-library).
Our tests should focus on user behavior? When writing that it seems obvious but it's easy to fall into implementation testing especially with Enzyme.
Both Enzyme and react-testing-library have great documentation, but I believe that the Enzyme API leans you towards testing implementation (state and props) whilst react-testing-library leans you towards testing user behavior.
This will require a different mindset when writing your tests.
The best thing about this mindset change is you are thinking about your users within your tests, thinking about how they interact with it rather than thinking about how the props and state objects look (implementation).
Focusing on testing users behavior rather than the implementation allows you to easily refactor code going forward. You want your user experience to be the same regardless of your implementation details…
As Kent C. Dodds puts it….
After spending years with Enzyme I felt I had to push through this mental barrier and start to move my focus towards the user’s behavior and react-testing-library really helps with that.
react-testing-library has changed the way I think about writing React tests.
One other huge benefit I experienced using react-testing-library was its guidance towards better code practices.
Guided Best Practices
react-testing-library selectors were another feature that triggered another mindset change for me.
The library has a limited number of ways you can interact with elements and they enforce you to use things like
placeholder, aria, test-ids to get access to elements.
A huge benefit of using these types of selectors is it feels like the tests are less likely to break vs standard ID and CSS selectors (most library’s use)
As I was driving my tests out I had to go back to my components to make them more accessible so I could test them. This is a great feedback loop.
Write tests > Build accessible components > Tests Pass
Not only can we benefit from more stable tests and better code, but more importantly our users benefit from an accessibility point of view.
Speed and Confidence
I was coming to react-testing-library new, and I was quite surprised at how fast I had something up and running and tests passing.
I feel like the barrier to entry for react-testing-library is lower than Enzyme but I’m not sure if that was down to my own personal experience with React as I started using Enzyme the same time I started with React so my experience would have been a lot different in general.
Another experience I had was the confidence in the tests.
Remember that time when you write a test and is passes and you can’t quite believe why…. so you go into your code and break the code to verify the test is actually working? This was my experience with react-testing-library… and quite a lot.
It feels with react-testing-library I had fewer issues writing tests than I have previously with Enzyme. The tests took longer to write (due to the fact I was still learning) but my confidence in the tests passing seemed higher than with Enzyme.
I feel overall writing tests with Enzyme can be faster than react-testing-library but I believe that’s a false positive.
react-testing-library forced me to think more about what I wanted to test and users behavior. I had to think differently and move away from implementation testing (which I feel is easier and natural with Enzyme) into more functional testing (which feels natural with react-testing-library).
I have had a great experience using Enzyme over the past few years testing React applications but with the exploration of react-testing-library my mindset has and continues to shift into what I believe is a better pattern of testing.
react-testing-library guides us to think more about best practices (selectors & accessibility), gives us more stable tests and allows us to test behavior vs implementation.
If you were like me and your default testing library of choice is Enzyme I highly recommend trying out react-testing-library and giving it the time it deserves to understand and see if it could help your teams and shape your tests.
Enzyme is still a great tool and a great open source project. But for me, I will continue to explore react-testing-library on future projects and try and make it my default React testing library of choice.
If you have any thoughts or experiences, I would like to hear them in the comments below. I hope you found this blog post valuable and good luck with your React testing!