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

I strongly agree with the guiding principles of RTL and have been using it for all new development that I can (specifically with the new Marko RTL wrapper). It has allowed us to catch severally A11Y issues already which is amazing since we already tried to avoid testing implementation details but making it easier to do goes a long way.

Having said that my current thinking is that for components there are really two people that need to be tested for. One is for the end user consuming your app, which is handled perfectly by RTL. The other of course is the consumer of the components.

In most frameworks the component consumer is interacting via props and events which are the public api for a component. To the end user it is an implementation detail, but it isn’t to the consumer. Having the ability to render and rerender components exists and is perfect for testing the prop API for components and there is usually some mechanism for testing events from the component such as spy’s. I definitely agree that accessing the component instance is not something the consumer would do and is an implementation detail, but testing props and events is and should be recommended to be tested.

All that is to say, I think RTL’s framework wrappers mostly handle that well, but I don’t feel like that clarification is made on the site. Primarily the wording appears to be about testing for the end user, which is great, but also the public api for components needs to be tested for the consumers of the component, which is often props and events emitted.

Unrelated, I have also been trying to reconcile the reasons why shallow rendering is so popular given the flaws that you mention in your article. I feel that your article highlights important points but might be a tad too absolute in its recommendation to avoid shallow rendering.

I think that using shallow rendering (especially with snapshots) does next to nothing as you say in terms of actually testing for the end user since 99% of the snapshot is testing implementation details. However I do think snapshots provide benefit to developers. They tell you when relevant sections of code has changed so that you can quickly and easily audit it, similar to comparing changes with git, except isolated to what an individual components renders.

However you could of course snapshot the entire rendered dom which would in fact give you more information about what was rendered, however I think at that point the level of noise is too much (similar to giant PR’s that no one wants to review) and so I think people opt for shallow rendering.

In Marko we are experimenting with a new technique which aims to snapshot the entire render tree while including minimal details about your child components. We are doing a full render of components (which means our equivalent of render props actually run which is nice!) and then are going to add the ability to clone the rendered DOM and strip out all nodes not owned by the component which you are testing. Meaning if you render a child component and pass children to it, only the children you passed would be in the snapshot, nothing rendered by the child.

And to end my list of ramblings, I feel that RTL (especially often being limited to JSDOM) is missing some tools to test as a user would, ie simulated scrolling, resizing, perhaps simpler tools for mouse and touch interactions as well? Perhaps good candidates for @testing-library/user-events.

Curious what your thoughts are on all this and thanks for your great work on this suite of tools!