Testing code is crucial for the maintainability of a complex code base, but it is just as important that tests are easy to write, maintain, and understand. Frontend code is no exception to this rule, and behaviors that live in your UI should be tested as well.

Almost three months ago, Airbnb open sourced Enzyme , a JavaScript library for testing React components. Since then, the reception has been extremely positive, currently with over 3,000 stars, and over 50 contributors, 45 of which are outside of Airbnb.

Historically, testing UI has been hard to accomplish for a variety of reasons, but using React removes a lot of these hurdles. We hope that enzyme does a good job removing the remaining ones!

Declarative UIs are Testable UIs

All new UI features for Airbnb.com are now implemented using React , which structures an application’s UI into a set of reusable “Components”. Components are a way to declare the way a UI should be rendered through an idempotent render function that is a pure function of application state.

Pure functions (and thus React components) are much easier to test because they simply return a description for what UI of the component should look like, given some application state, rather than actually mutating the UI and having side-effects. This “description” is known as a “Virtual DOM” and is a tree-like data structure.

Making assertions on the state of a React render tree can include a lot of boilerplate code and is hard to read, which detracts from the value of the test. Moreover, directly asserting on the resulting tree can strongly couple your tests to implementation details that end up making your tests extremely fragile.

Enzyme makes asking questions about the rendered output of your React components easy and intuitive by providing a fluent interface around rendered React components.

React Conf 2016

I gave a lightning talk about Enzyme and testing react components at the React Conference last week. If you haven’t seen it yet, check it out!

Example

To see how Enzyme works, let’s take a look at an example: The “To Do” list.

Say we have these two components:

This is a relatively simple example, but let’s see what kind of assertions we can make.

Enzyme exports three different “modes” to render and test components, shallow , mount , and render . S hallow is the recommended mode to start with since it does a better job of isolating your tests to just a single component. If shallow doesn’t work for your use case (for example, if you are relying on the presence of a real DOM), mount or render likely will.

*Note: This example will use a combination of mocha and chai expect , but neither are required to use enzyme.

We can also test the ToDoList component:

And then we’re done!

How does this compare to React’s TestUtils?

If you’ve tried to test React components before, you might be aware that React provides testing utilities to achieve some of the same goals.

Enzyme uses several of the utilities provided by React to build its API, but provides a much different interface and several more methods to reduce boilerplate and reduce the coupling between your tests and your implementation.

Moving Forward

The problems that Enzyme addresses are by no means specific to Airbnb. Hopefully, by open sourcing Enzyme many others will find testing React components easier and more approachable. We have a number of features planned for future development , and welcome contributions from the community. You can fork Enzyme or open feature requests in the Github repository .