Testing In React, Part 2: React Testing Library
The headline for React Testing Library is, “Test functionality, not implementation”. The idea behind this concept is that implementation is constantly being iterated and improved upon, and therefore is unreliable as a means of testing a UX.

For example, let’s say you are working on a small React component for which, early on, you write tests. The component handles a certain amount of logic and renders something to the DOM. As your application grows, so does this component, and eventually it makes sense to break it up into multiple components. As far as the user is concerned, nothing has changed — what is being rendered to the DOM is still the same. In other words, you have changed only the implementation, but not the functionality.

If your initial tests were written to test implementation, they would break. But by testing the functionality — DOM nodes rather than rendered components — your tests continue to pass (unless you screw up the refactoring, of course).

A quick note before we start: Jest and React Testing Library are used very much in conjunction with one another, and while I think it is helpful to focus on each separately, it is nearly impossible to talk about one without the other. You can think of Jest as doing the actual testing, while React Testing Library recreates the thing to be tested (be it an event, a node, etc.). Any Jest functionality referred to here will be covered in depth in my next post.
['Bryn Bennett']
['React', 'Programming', 'Software Testing', 'JavaScript', 'Software Development']