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:

The different ways to use CSS :has(), with examples

The CSS :has() pseudo-class is a powerful new feature that lets you style parents, siblings, and more – writing cleaner, more dynamic CSS with less JavaScript.

Daniel Schwarz
Oct 24, 2025 ⋅ 7 min read

Kombai AI: The AI agent built for frontend development

Kombai AI converts Figma designs into clean, responsive frontend code. It helps developers build production-ready UIs faster while keeping design accuracy and code quality intact.

Jude Miracle
Oct 23, 2025 ⋅ 7 min read

The Replay (10/22/25): AI-assisted coding, Wasm 3.0, and more

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 22nd issue.

Matt MacCormack
Oct 22, 2025 ⋅ 29 sec read
Where AI-assisted coding accelerates development — and where it doesn’t

Where AI-assisted coding accelerates development — and where it doesn’t

John Reilly discusses how software development has been changed by the innovations of AI: both the positives and the negatives.

John Reilly
Oct 22, 2025 ⋅ 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

Hey there, want to help make our blog better?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now