React was designed to solve one problem—how to build applications with data that changes over time. Considering the as-you-type search experience offered by Algolia wherein whole results pages, hits and refinement links alike, are updated at each keystroke, React was the obvious choice when we needed a tool to build out our new library of UI widgets: instantsearch.js.
We quickly struggled, however, with the unit test best practices for React components. We jumped from Github issues in facebook/react to blog posts and discuss.reactjs.org but couldn’t find a clear unit testing strategy.
Here’s an example of a Button and a Label component tested with mocha:
And here is the output when you run it:
What about failing test cases? Let’s make it fail by changing our test:
Not too bad. Shallow rendering provides a way to render a React element onlyone level deep. This means that if you have children elements (like Label in our Button), it will not trigger their render methods. Very nice for unit testing!
The shallow rendering technique is simple to use and well suited for unit testing as it takes a React Element as INPUT and produces a React Element as OUTPUT.
There are other techniques available, but this is the currently recommended one and we expect (?) the React team to develop more tools around it in the future.
But wait, it’s not over! Did you see that diff? You passed some nice expected JSX (<div><Label name=”Marie” /></div>), and all you got was a weird object output diff.
This is because JSX is transpiled to a React.createElement call that then returns a React element (a JavaScript object). So when doing expect(something).toEqual(somethingElse), you are just comparing two JavaScript objects.
It would be better to get something like this:
Let’s make it happen! OK, we need a bit of tooling to get there.
What is the rackt team using?
After we found out about shallow rendering, we needed a good stack to make assertions and run the tests. We decided to have a look at what rackt, the Github org responsible for react-router and redux (two very popular react libraries) was using. After all, the closer you are to the tools of your community, the easier it is to get contributions.
The rackt team is using mochajs/mocha to run the tests and mjackson/expect to write assertions. They also follow the facebook/jest convention of putting tests next to the files they are testing:
Introducing expect-jsx
After choosing mjackson/expect as our assertion library and mochajs/mocha as our test runner, we wanted better JSX diffs instead of long object diffs when our tests were failing.
Unfortunately, those libraries were not meeting our expectations. So…we built algolia/expect-jsx.
Let’s enhance our previous test with this new module:
expect-jsx transforms the passed React elements to JSX strings to nicely compare them. This seems a rather naive approach, but this is completely OK for unit testing.
Using expect-jsx will save you a good amount of time and spare you from having to write things like expect(result.props.children[0].props.children.className).toEqual(‘U mad?’);
Warning: If you use Karma runner to launch mocha tests within browsers, you will not have any nice object or string diff. This is currently an issue in the html-reporter.
This means you have to resort to directly calling the underlying function of your handlers props. Doing so doesn’t introduce any test-specific nonsense, as it’s the same thing Simulate would do in the end.
Let’s change our Button component to illustrate this:
Our test now looks like:
As you can see on line 24, we’re just calling the props.onClick handler directly to check that our custom handler has been called properly. Easy, right?
Well, that’s the way we unit test our component handlers. If you have a better solution, leave it in the comments!
Testing using references
Shallow rendering does not have access to any references you may have defined in your Component, so you cannot use them when testing with the shallow rendering technique. This is being investigated by the React team.
In the meantime test your refs dependent Components using the standard Test Utilities.
npm run test:watch
At Algolia, we try to minimize the entry cost to a project for any developer. All projects have an npm run test:watch task that we can use to TDD with a rapid feedback loop.
You can easily get one by adding the following to your package.json:
Your development workflow will then look like this: