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:

what are the event loop and call stack in JavaScript

What are the event loop and call stack in JavaScript?

Learn how the call stack, event loop, and various queues help JavaScript handle asynchronous operations while maintaining its single-threaded nature.

Ikeh Akinyemi
Feb 18, 2025 â‹… 6 min read

React Context tutorial: Complete guide with practical examples

Let’s review React Context API. When should you use it to avoid prop drilling, and how does it compare to Redux?

Adebiyi Adedotun
Feb 17, 2025 â‹… 13 min read
how and when to use JavaScript arrow functions

How and when to use JavaScript arrow functions

Arrow functions have a simpler syntax than standard functions, and there are some important differences in how they behave.

Joe Attardi
Feb 17, 2025 â‹… 5 min read
javascript is null or empty function

How to check for null, undefined, or empty values in JavaScript

In most languages, we only have to cater to null. But in JavaScript, we have to cater to both null and undefined. How do we do that?

Lewis Cianci
Feb 14, 2025 â‹… 4 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