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

View post

Ameem Shaik • Jul 21 '19 • Edited

Overall I think it's great and solves many of the issues with enzyme.

My favorite parts are:

It prevents you from accessing the instance. This is the most common testing mistake I see in the code bases I work on-- calling .instance() and then directly invoking an internal method for testing.
It prevents you from querying by the component name, e.g. expect(wrapper.find(MyComponent)).toEqual(...). This is especially an issue when writing integration tests with enzyme, as the component structure is really just an implementation detail at that point. I think static rendering (render()) might be a better option, but most people just seem to use mount. In any case, that leads to my next point:
Much smaller, simpler API. Enzyme provides so much functionality that it can be really hard to figure out the right approach for a given situation. Even worse is that much of the functionality can lead to really brittle tests. There's just a lot less decision making with RTL.

Steven Liao • Jul 21 '19

RTL doesn't prevent you from accessing the instance since it's still possible to get the instance by

const ref = React.createRef();
const testUtils = render(<ClassComponent ref={ref} />;
const instance = ref.current;

The fact that RTL does not provide an instance() API certainly does discourage accessing the instance though, and I agree with that. I also agree with all your parts.

Ameem Shaik • Jul 21 '19

True, "prevent" was probably the wrong word to use here!

Kent C. Dodds • Jul 21 '19

I use the word "enable"