How we unit test React components using expect-jsx

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 but couldn’t find a clear unit testing strategy.

Now that we’re happy with our testing stack, we wanted to share it with the community to hopefully make your testing process a bit easier. Feel free to also check out the unit testing tips we shared a few months ago.

How to test a React component

Before digging into the whole testing stack, how do we test a React component?


If you search for “React unit testing”, you’ll quickly find the popular React discussion—What’s the preferred way to test React.js components? In the thread, React developer Ben Alpert advises testing React components using a technique known as shallow rendering.

Here’s an example of a Button and a Label component tested with mocha:

And here is the output when you run it:

2015-10-20-150031_890x197_scrotWhat about failing test cases? Let’s make it fail by changing our test:

2015-10-20-150207_1061x621_scrotNot too bad. Shallow rendering provides a way to render a React element only one 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:

2015-10-20-152034_977x396_scrotLet’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.

We asked the React community how to do this and got some great feedback. In fact, another assertion library already did it—bruderstein/unexpected-react-shallow. alexlande/react-to-jsx was also a candidate for implementing the JSX string diff in the expect assertion library.

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?’);

expect-jsx is based on algolia/react-element-to-jsx-string. This means that if you’re using tape, chaijs or jasmine, you can easily build the same assertions goodness within a day and publish it to npm.

Since we released react-element-to-jsx-string, developers have implemented JSX diff in multiple assertion libraries:

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.

Simulating events like onClick

As of today, the shallow rendering technique does not support simulating clicks using React test utilities Simulate.

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:


Where to go from here?

The whole code used in this article can be found at algolia/react-test-boilerplate.

If you need some DOM features in your tests, check out tmpvar/jsdom and rstacruz/mocha-jsdom.

If you need to run your tests in real browsers, you can use karma-runner or defunctzombie/zuul coupled with Sauce Labs or Browser Stack.

If you liked this post and are interested in a follow-up article about those subjects, leave a comment or tweet @algolia.

Happy coding!

Learn more

Update November 02 2015

We did a talk about this at ReactJS Paris, here are the slides:


  • Nicolas Martel

    Loving this.

  • Comparing actual and expected JSX – common dude, you serious? 🙁 Instead of using “onClick” as props, you should use React TestUtils Simulate…

    Yeah It (TestUtils) is not working for now with shallow rendering (it expects window in global), you should inject `global.window` with jsdom to get gears spinning.

    I recommend you to use jsdom and test your components right way.
    I use `mocha-jsdom` module for sugar DOM injecting in global space.

    Sorry for being hot temper, I hope my comment will be helpful.

    I can explain (why I chosed jsdom) and give a link to repo if you’re interested in it.

    • Hi ColCh, thanks for commenting.

      I am sorry I did not get your issue about “Comparing actual and expected JSX – common dude, you serious?” How do you test the structure of your render method as part of your unit testing strategy?

      Yet you can use TestUtils.simulate but that’s a different need, first we need to ensure the structure that is generated is the one we are expecting (nodes, text, classes ..) and then we want to test the behavior of the handlers.

      For the first part (structure), comparing JSX is a nice solution, there are others and maybe that’s what you wanted to say?

      For the second part we do say that if you need it you can use TestUtils.simulate and use mocha-jsdom as we already use also at Algolia.

      Thanks for contributing.

      • Hi. We stick with BEM naming approach. So, in tests we just find elements by ClassName and manipulate with them (and make assertions).

        I don’t recommend to assert JSX because it’s doubling of your layout – it’s getting very hard to refactor components in future.

        • Actually we did already refactor a lot of them and it was not so painful. It really depends on the usecase I guess.

          Doing find by class name can be tricky because you do not assert the underlying structure, and we need to. The structure could be completely broken and it would still work in the test.

          Unit testing is a lot about unit taste(ing) 🙂

          • Agree. So, I didn’t know your case for testing 🙂

  • Jon Perl

    Thank you this is super helpful. I also found your instant search feature through this — we are definitely using that in our next major project, that demo is insanely awesome.

  • franleplant

    Good resource, first of it’s kind. Good coverage of testing handlers

  • Adam Beck

    How are you using mocha with this?

  • oksas

    Thanks so much for putting this together! The boiler plate project on GitHub is really useful 😀

    I followed all these steps and tried running my test command, only for npm to tell me that it couldn’t find “babel/register”, I presume because some of the changes to babel in version 6, I think? I’m not entirely sure what’s behind it, but to get around this, I had to run `npm install babel-register`, and in my mocha.opts file, change `js:babel/register` to `js:babel-register`, which did the trick 😀

    • oksas

      Update! Apparently in the latest babel, the `register` bit is now part of the `babel-core` package and not the `babel` package, so a better solution to what I said above would be to simply use the `babel-core` package instead of `babel` (ie your package.json’s dependencies should have `babel-core` and not `babel`, I think?), and in mocha.opts, change `js:babel/register` to `js:babel-core/register` and all will be well. No need to separately install `babel-register` or anything like that.

      • Hi oksas, thanks for the comment. Can you open a github issue on the boilerplate project so we can fix it? Thanks

        • oksas

          Just filed an issue. Sorry for the slowness!

          • Fixed the repo and the article to work with babel6, thanks!

  • Great article. However I did go for airbnb’s enzyme for now, because of the nicer API. Do you have any experience with it? Is there a way to use both libs together?

  • Thanks, those example where very helpful as I’m facing the same type of situation.