Discussion on: What do you think of React Testing Library?

[Steven Liao]

I've been using RTL personally and love it so far. The ideology behind it makes so much sense.

However, I have to use Enzyme at work and it makes following the idea behind RTL so much harder. Finding elements with Enzyme returns a bunch of implementation details that don't usually don't really help.

I had tried to convince the frontend architect at my company to switch over to RTL for testing. He had tried it but didn't like it for a couple of reasons:

• There is no shallow rendering (I believe he loves unit testing components). He believes that each component and test should be isolated from one another, so that tests would not bleed into one another, making tests less brittle than rendering the entire tree.
• Rendering the entire tree with RTL makes it really ez to have huge, unmaintainable tests. I told him it is possible to unit test with RTL, but he said the fact that the default is full DOM rendering just makes it to ez to not unit test.

I had argued that shallow rendering does not give the confidence that the code works, but he said there needs to be a balance for maintainability. I proposed adding RTL to the codebase to allow everyone to try it out but he argued that when a developer encounters a test in RTL, the developer would have to learn a whole different set of testing API to make changes to the test.

I honestly still think RTL makes the better trade-off though because I followed its ideology in Enzyme and it has actually caught bugs for me.

[Ameem Shaik]

Have you tried using Jest mocks to replicate shallow rendering? If not, maybe try suggesting this approach to your architect. See FAQ for more info.

Using Jest mocks is actually a more powerful approach anyways, since it allows you to explicitly choose which components to mock. With shallow, all components are mocked, even if they're defined in the same file.

[Steven Liao]

Yep. His concern was that it's too ez to not mock and then developers would put a bunch of tests into the component higher up in the tree, making it harder to maintain, whereas when shallow rendering just mocks as much as possible, encouraging to test whatever the current component does.

[Kent C. Dodds]

I should write about this. People who complain that tests break a lot when testing this way don't understand that they're breaking for the right reasons whereas testing implemention details makes your tests break for the wrong reasons. Ugh.

[Steven Liao]

:/ Ever since I learned about the RTL ideology, using Enzyme has just been pretty miserable for me. It's so ez to test an implementation detail, find elements that also return the Component element rather than just the DOM element.

At work, I mostly see shallow rendering, expecting this shallow wrapper to match snapshot, expecting wrapper.state('whatever') to equal something... Don't really wanna start any crap so I try not to say anything.

Also, I can't seem to find another reliable way in Enzyme to wait for an async componentDidMount besides returning the promise inside componentDidMount and awaiting. I don't really like this approach though... because it relies on implementation detail.

// something.tsx
componentDidMount() {
  return promise
}

// something.test.tsx
await wrapper.instance().componentDidMount()
wrapper.update()
expect(...)...

The frontend architect at my company endorses this pattern. So I'm pretty much forced to use this pattern since I can't use RTL waitForElement.

Btw, looking forward to your talk at useReactNYC on Tuesday.

[Kent C. Dodds]

Sweet! Let me know who you are! Looking forward to meeting you.