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:

Using Aws Lambda And Aws Cloudfront To Optimize Image Handling

Using AWS Lambda and CloudFront to optimize image handling

Leverage services like AWS Lambda, CloudFront, and S3 to handle images more effectively, optimizing performance and providing a better UX.

Nitish Sharma
Apr 12, 2024 ⋅ 12 min read
Building Web-Based Terminal Components With Termino.js

Building web-based terminal components with Termino.js

Explore Termino.js, an open source library for integrating web-based terminals into applications, in this introduction article.

Chibuike Nwachukwu
Apr 11, 2024 ⋅ 6 min read
How To Build A Custom Gpt: Step By Step Tutorial

How to build a custom GPT: Step-by-step tutorial

Let’s see why and how to build custom GPTs — personalized versions of ChatGPT that act as custom chatbots to serve a specific purpose.

Peter Aideloje
Apr 10, 2024 ⋅ 7 min read
Jest Adoption Guide: Overview, Examples, And Alternatives

Jest adoption guide: Overview, examples, and alternatives

Jest is feature-rich testing framework that comes with several in-built features that make it powerful and easy to use.

Ibiyemi Adewakun
Apr 9, 2024 ⋅ 12 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