What's the prefered way to test React.js components?


(Patrick Aljord) #1

Is there a recommended solution?


(Sophie Alpert) #2

Shallow rendering is our current recommendation – a new feature introduced in React 0.13. It allows you to instantiate a component and get the result of its render function (a ReactElement object). At that point you can inspect its .type and .props to verify that the correct result was rendered. This avoids having to use functions like mockComponent, which are fragile and environment-specific.

I think we missed this in the 0.13 announcement and are planning to have a blog post with more details in the near future.

(As for a test runner, most people use either Karma or Jest.)


(Dmitry Manannikov) #3

I use mocha+jsdom+mockery.
I try Jest before, but tests start time not so good.


(Ryanzec) #4

I use Mocha/Chai/JSDom to test my components. I have never been a fan of the “mock everything expect what you are testing” philosophy which is why I don’t use Jest.


(Tmcw) #5

I’ve been using tape for tests, just like a node module, and smokestack to run them headlessly on smokestack. This way it’s possible to run tests in ‘debug mode’ in the same real browser they run in on a CLI.


(Robertknight) #6

I’ve found the mocha+chai+JSDOM combination to work well. I have a demo repository at https://github.com/robertknight/react-testing showing how to do testing of components with various approaches - shallow rendering, mocking, renderToString(), React.TestUtils.

The slides from a related talk I did at the React London meetup - https://robertknight.github.io/react-testing/docs/react-london-talk.html#1


(Nhunzaker) #7

To speak on running tests, I use Karma to run the Mocha test framework, Chai for assertions, and Sinon for mocks, stubs, spys, etc.

So far I’ve been very happy with it for a number of reasons.

  1. It integrates well with Webpack
  2. I love running tests in multiple real browsers, the utility here is arguable however it gives me greater confidence. It is easy to set up Karma to execute in single browser in development however send out a request to test a ton of environments with something like BrowserStack on CI.

What could be better:

  1. The test runner watch mode can get strange, particularly on larger projects.
  2. Using the Webpack plugin on large projects gets slow (there are work arounds)

Beyond that, it’s definitely getting the job done for us!


(Radu Brehar) #8

I’m also using mocha+jsdom (+shouldjs). Can share a link to working tests if wanted. Also with CI in the mix.


(James Burnett) #9

We started with Jest, and it made things relatively easy at first. However, Jest had serious problems when trying to setMock. Also, Jest is limited to node 0.10 and JSDOM 0.10, with virtually no possibility to upgrade ever (I have personally spent hours tracking down the issues and eventually stopped when I hit problems with faketimers). So we had to switch to Mocha + JSDOM.

Mocha worked really well until recently, when we discovered issues with React.addons.TestUtils.renderIntoDocument and deep child components that have refs. Now we are discussing options. So far, it looks like we are going to go with shallowRenderer, which we were already starting to use. It seems unlikely that testing will change much once the long and painful process of converting our entire test suite to shallowRender is done.


(Tommy) #10

Is there any example using the Shallow rendering technique?


(Dan Abramov) #11

Docs and tests are a good place to start.


(Robertknight) #12

https://github.com/robertknight/react-testing/blob/master/tests/TweetList_test.js#L73

The docs that @gaearon linked to show the APIs. There is an example in the repo I mentioned above showing how to use each of the different approaches (including shallow rendering) to test a component displaying a list of tweets.


(Eric Masiello) #13

I’d love to see an example


(Maurizio Mangione) #14

Shallow rendering is really cool! I used it to write some tests in my react starter kit using Mocha and Chai.
Suggestion for improvements are welcome.


(Rodeoclash) #15

How do you go about testing components which pass callbacks to children with shallow render?

E.g. I might have a component, something like:

<tab onChange={this.handleChange.bind(this}>

In our current Mocha/JSDOM tests, I would reach into the child components props and trigger the onChange callback with an attribute. I would then inspect the re-rendered component to check it matched what I expected.

With the shallow testing this goes out the window as the child doesn’t exist. How are others testing shallow rendered components that have callbacks?


(Liam Brown) #16

Shallow rendering sounds great, but it is limited compared to using a fake DOM. Being able to use TestUtils.Simulate to fire button clicks and change events for input controls is something that I could not do without in my testing - this means, for one, that you can ensure with unit tests that onClicks and onChanges are hooked up as expected. As far as I can see, this would not be possible with shallow rendered - I hope I am wrong?


(Johannes Troeger) #17

Right now it is not possible to use ReactTestUtils.Simulate with Shallow rendering and i think the issue to follow should be: https://github.com/facebook/react/issues/1445


(Radu Brehar) #18

See https://github.com/zippyui/react-datagrid/tree/master/test for example tests using mocha/jsdom/should


(Killavus) #19

I wrote a rather lengthy blogpost about testing approaches I tried and used. Shallow rendering is a very nice choice, but it has its issues. In fact, each of testing approaches I know about React results in some kind of trade-offs.

I hope you find it useful: http://reactkungfu.com/2015/07/approaches-to-testing-react-components-an-overview/


(Eguneys) #20

Awesome post. Could you take a look at this: http://stackoverflow.com/questions/31459720/how-to-test-decorated-react-component-with-shallow-rendering