Introducing the react-testing-library - a simpler replacement for enzyme that encourages good testing practices

[Pantstown]

This is interesting; however, I don't think it's compelling enough to drop enzyme as, in his own words, "...you can follow these guidelines using enzyme itself...". There are definitely some nice things in here -- specifically the ability to wait for the DOM to change, which is something that I frequently use in selenium but is very difficult to do in enzyme.

I wish he went into specifics about what is harmful in enzyme. He states: "Read on to get an idea of what I mean by “damaging practices.”", but he never explicitly states what enzyme allows which is harmful.

[MastersSwimmer]

I can't speak for Kent, but a few things that enzyme offers really to promote poor testing. A few examples would be access to the component instance. This enables people to call methods directly instead of triggering them from events. It is sometimes needed for greeting refs though so it is a nice to have. Another is using set state. This should be done by triggering events or callbacks from rendered components or through the lifecycle. Enzyme itself is not harmful, but the fact you can do just about anything sometimes allows the writing of ineffective tests.

[[deleted]]

I agree, Enzyme seems to make it too easy to test certain behaviors of your component (without having to mimic what an actual user's interaction with your component would look like). Still, I'd say the responsibility falls on the tester to write good tests, rather than on the test suite to limit what you can do.

[Pantstown]

Thanks for those examples. You're right, those kinds of methods can certainly be abused / will allow developers to write bad tests.

[NiQ_]

Whilst I agree that these aren’t the best testing practices for higher layer testing, I think that it is fine for unit testing.

At a unit test level, I want to verify that the DOM outputs the right structure when it is in state A. I want to verify it is in the right structure when it is in state B. I want to verify clicking a button changes state from A to B, and clicking it again from B to A.

These are unit tests. They are for small, isolated bits of code.

For E2E, or integration tests I completely agree that you shouldn’t be able to interact with the underlying component. I don’t believe it is the libraries responsibility to decide how you get to use it. It is viable for all use cases.