Testing solutions for React and Flux

At YPlan, we care a lot about the quality of our products.
We move fast (and break things, of course) and we want to make sure that our users are always happy.

Apart from working with love everyday, one thing we can do to achieve our goal is to write a good number of tests. The component-based nature of React comes handy in this process because components are easy to test.

The tools we decided to use to test our components are Jest, which we love because it mocks every dependencies by default, and the TestUtils, a set of utilities created by Facebook to make testing easier.

Writing more and more tests, we found some useful solutions and patterns to solve recurring problems and that’s what this blog post is about.

First of all, let’s have a look on what testing a React component with the TestUtils looks like. Suppose we want to test the following button:

There are three different ways of doing it, according to what we want to achieve and what we want to test.

Render into document

The first one is the most common: in essence, using the TestUtils, we render the component (and its children) into a fake DOM so we can operate on it and make some assertions. This method is useful if you want to test a real instance of the component.

Shallow rendering

In React 0.13 has been introduced a new way of testing components, which make tests more unitary: the shallow rendering.
Using the shallow rendering, components are not renderer into a DOM but we can make assertions on the output of the render method, which is a React Element.

Render to static markup

In some particular cases (integrations tests, for example) it could be useful to render our components to static markup and check if the generated html code is the one we expect it to be.

Component will receive props

Testing a simple button is fine, but when it comes to test real world components things get more complex. For example: what if we want to test the behaviour of a component when it receives new props?

The componentWillReceiveProps lifecycle method is fired when a components receives new props from the parent and it doesn’t get called during the initial rendering. For example, the following component has a default title until it receives a new one as a property and it re-renders itself with the new heading.

Modifying a React component’s props is a bad practice, so we adopted a different solution: setting the state of the parent. To test our Header component we just wrap it inside a Parent and we change its state so it re-renders itself and the child with the new props. At that point, we can make assertions on the result, like this:

Context

The context is React feature that is very useful in some scenarios and it has been documented recently, even if a lot of libraries were using it since months. Suppose to have a Label component which receives its text via the context.

Testing it is non-trivial and the best solution we found to do it is to create a Parent component which passes the needed context to our Label so we can make assertions on it, as follows:

This package helps you creating stub contexts.

Flux

The last common solution we found is related to Flux. At YPlan we use the classic Flux implementation and we want to make sure that our Stores behaves correctly when they receive data within actions. The trick here is to grab the callback from the Dispatcher’s mock and use it to fire actions.

Recently, we started using Enzyme, a testing utility created by AirBnb which make easier to manipulate and traverse Components’s output: a blogpost will come soon.