This article on using snapshot testing to find side effects from component errors in JavaScript originally appeared on xMatters.com.

In its history, testing the front-end has been always somewhat of an afterthought — as long as the UI looks okay, it’s all good. After all, if the back-end doesn’t function correctly, who cares if your UI is a bit buggy?

However, in the last few years, especially after the advent of Single Page Apps, the front end has become an extremely important part of a product. Across many different devices and technologies, the UI is the primary way in which users interact with any product. So, the robustness and the resilience of the front-end has become of utmost importance. This, combined with larger teams focusing on the front-end, necessitates better and more careful testing practices.

In xMatters we have been using React for the past few years, and have strived to create good tests with good coverage without getting in the way of developers.

We’ve found Jest to work very well for us, especially its introduction of the idea of “snapshot testing” which delivers very resilient and fast tests.

In this post, I’ll be focusing on the evolution of how people tested their JavaScript on the front-end historically through today. I’ll highlight some methods that have worked well for us at xMatters, both in terms of understanding what it is we’re really interested in testing and avoiding pitfalls that might slip by otherwise unnoticed.

Checking Side-Effects

Most unit tests we’ve learned to write in the past amount to what is essentially checking for “side-effects” of our components. Often, we might check for the number of elements on a list, assert if a class name is present, or check that the content matches.

Unfortunately, in a codebase that promotes re-use of components and gets contributions from a lot of different developers, such tests can miss breaking changes easily. I will try to illustrate below how even the smallest mistakes can provide false-positives or false-negatives.