2023-03-23
2143
#react
Will Soares
17965
Mar 23, 2023 â‹… 7 min read

Testing React components: react-testing-library vs. Enzyme

Will Soares I'm a front-end developer and writer based in Porto, Portugal. For more posts, check out willamesoares.com.

Recent posts:

Actix Web Adoption Guide: Overview, Examples, And Alternatives

Actix Web adoption guide: Overview, examples, and alternatives

Actix Web is definitely a compelling option to consider, whether you are starting a new project or considering a framework switch.

Eze Sunday
Mar 18, 2024 â‹… 8 min read
Getting Started With NativeWind: Tailwind For React Native

Getting started with NativeWind: Tailwind for React Native

Explore the integration of Tailwind CSS with React Native through NativeWind for responsive mobile design.

Chinwike Maduabuchi
Mar 15, 2024 â‹… 11 min read
Developing A Cross Platform Tv App With React Native

Developing a cross-platform TV app with React Native

The react-tv-space-navigation library offers a comprehensive solution for developing a cross-platform TV app with React Native.

Emmanuel Odioko
Mar 14, 2024 â‹… 10 min read
Essential Tools For Implementing React Panel Layouts

Essential tools for implementing React panel layouts

Explore some of the best tools in the React ecosystem for creating dynamic panel layouts, including react-resizable-layout and react-resizable-panels.

David Omotayo
Mar 13, 2024 â‹… 8 min read
View all posts

3 Replies to "Testing React components: react-testing-library vs. Enzyme"

  1. That is just an amazing and great comparison. Very elaborate, yet concise.
    Thank you very much.
    It’s like bkack-box testing (react-testing-library) versus white-box testing (enzyme) or BDD (react-testing-library) versus unit-testing (Enzyme).
    This blog certainly made me continue in the direction of react-testing-library.

  2. Hey Jarl, thanks for the feedback!

    That’s exactly how I think about those two tools and the reason why I think people should look more into tools that test user behavior over code. In general it gives you more confidence on how users are in fact perceiving your app.

  3. Thanks for writing this up, though as a fan of Enzyme, I feel like it’s being a bit misrepresented here.

    1) In enzyme you absolutely can simulate a user click:
    `wrapper.find(SELECTOR).simulate(‘click’)`
    And from there the developer can choose how they want to assert that it was handled correctly (state value, or actual display)

    2) While it is true that RTL allows for more user-facing ways of interacting with the code, it seems to do so at the expense of allowing many other developer-only ways of interacting with the code (without polluting production).

    If I want to test that a certain sub-component ( or ) is rendered given certain business logic conditions, with RTL I have two options:
    A) Peek into the downstream HTML and confirm it’s there
    B) Apply some sort of additional label, like a data-testid

    A is faulty since it balloons the scope of tests, and B feels like a code smell of including test-only code in production files.

    Ultimately, it’s possible that I just need to give up the idea that certain things are ever testable in the clear-cut way that I’ve grown accustomed to, and embrace this more ‘hit and run’ style of testing. I just can’t shake the feeling that I’m compromising too much on the core ideology of my test code, which is to help prevent accidental regressions and instill a sense of safety when refactoring.

Leave a Reply