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

(Vincent Voyer) #21

We just published a blog post sumarizing our findings about unit testing React components: https://blog.algolia.com/how-we-unit-test-react-components-using-expect-jsx/

We presented this at ReactJS Paris this month: http://slides.com/vvo/react-component-unit-testing/

tl;dr; Use shallow rendering when feasible, otherwise regular test utilities.

Shallow rendering limitations: refs (problematic), simulate (not so much)

(Dave Brotherstone) #22

I’ve just written this up too, which allows tests against the virtual DOM - https://medium.com/@bruderstein/the-missing-piece-to-the-react-testing-puzzle-c51cd30df7a0

The project is https://github.com/bruderstein/unexpected-react

(Wout mertens) #23

A more meta question: did the tests you wrote uncover bugs?

I like unit tests but when creating React Components it seems to me that just looking at the component while coding it (with hot reload) is enough to cover the “it should display tweets” and “clicking calls onclick” functionality.

The bugs we get are more the “here are some unexpected props contents” and “it doesn’t seem quite centered with a long string” kind. How do you test for those?

(Justin808) #24

I’d second @wmertens comment. Testing react components (unless you’re writing a library) reminds me of testing views in Rails. All this does is make double the work when you’re iterating over the UX. Much more critical is end-to-end integration testing using something like PhantomJS and Capybara.

That being said, I’d love to hear others experiences with the practicality of writing many React component tests.

(Trevor D. Miller) #25

There is an egghead.io course of video lessons on it:

(Trevor D. Miller) #26

I really really like Shallow Rendering. Its nice to not need a DOM - the tests run so fast! - and it forces me to keep my tests modular. There is an egghead.io course of video lessons on it:

The course walks through setting up a React testing environment, using the Shallow Render to test component output, and breaking utility modules out into their files to test them separately. It also includes a few lessons on testing Flux/Redux. Some of the lessons are free, some require a subscription. Hope this is helpful :slight_smile:

(Con Antonakos) #27

What do you all think about http://airbnb.io/enzyme/?

(Bobby Steinbach) #28

As far as acceptance testing is concerned, is anyone else using CasperJS? I’m having a hell of a time simulating events (specifically the selection of options) inside my testing script. Would love if somebody could point me in the right direction (P.S. SO question asked here: http://stackoverflow.com/questions/35567735/trigger-select-change-in-react-app-with-casperjs)

(Juan Mendes) #29

You do not have to test React Internals, think in broader terms. Say I create a <Grid> and I added functionality that it displays a “no data” if you don’t pass in any rows (or after it requests it from some API), I want to make sure that my grid does correctly display that message.

I don’t think I’m duplicating React testing if I render it and query the DOM looking for that message. Maybe I don’t even have to render it, I can just examine the state of my Element.

Integration test is way more expensive than unit tests, if all your tests are integration tests and you want to cover all cases, you’ll be running integration tests for 12 hours (as we did in a previous company).

I use integration test only for basic tests that make sure the integration between client and server and DB is working.

In response to @wmertens comment, you can surely measure the offset of objects to make sure they are centered.

(Sahas ) #30

Battle around right mix of GUI tests are hot topic anyday. I’ve been thru this flaky end-end tests in the past and recently started tacking them with some rationale based on the usecase/ test case intentions.

1# If your intention is to simulate something within one view - prefer view testing. React TestUtils + Mocha + JsDOM works well for most cases. React TestUtils, browser event simulation is a great plus compared to other SPA frameworks out there. ie. Angular doesn’t have something like this… or atleast not as easy as React.
I’m using wiremock to virtualize the services so that even if my back-end is unavailable, my view tests will continue to work as long as the contract wasn’t changed.

2# If your intention goes across several views - webdriver is the better choice. However, since we have enough coverage from view tests, webdriver tests can focus on the user journey rather than focusing on little items like “user name should be auto focused when user navigates customer edit”.

3# If your intention is to verify some data - UI has little to do with it and hence why not directly hit the APIs and test. Use API testing tools. This is mostly related to back-end development.

So, IMO, as far as testing react components, more and more #1 compared to #2 should help us to keep them green for long run.
Just my 2 cents, happy to learn what others have experienced here…

(Con Antonakos) #31

Anyone have a good way of integrating Mocha + Webpack with absolute route resolutions in their required statements? For example, I have littered all over my application “import Example from components/Example” rather than “import Example from …/Example”. So I need a way for Mocha to read the file prepared by Webpack and trigger the tests. Any thoughts?

(Alexander Christiansson) #32

I use https://github.com/zinserjan/mocha-webpack. It works well with custom resolve paths. It also does incremental webpack builds when watching so the slowness caused by piping all tests through webpack is not that bad.

(Con Antonakos) #33

Awesome. I’ll check that out. Thanks!

(Krasimir) #34

As @ConAntonakos mentioned I found that one of best utilities for testing React components is https://github.com/airbnb/enzyme . It supports shallow rendering and the usual rendering + has a really simple and friendly API.

(Develerltd) #35

Using enzyme with jest and it works remarkably well.

(agarick) #37

I’ve also started using enzyme (with mocha and chai, like the enzyme docs), and it seems pleasant enough. No further configuration on mocha’s part and enzyme just works.

From what I’ve read, enzyme is a wrapper around react-test-utils, including the shallow render.

(Tien Do) #38

I found Jest is fast, easy to use, good document. Snapshot testing is great to see if you broke component UI anytime. Interactive mode when running Jest with --watch parameter is really cool too.

A case study: https://blog.grommet.io/post/2016/09/01/how-we-landed-on-jest-snapshot-testing-for-javascript

(Tien Do) #39

FYI, Kent just published a new article: Migrating to Jest :slight_smile:

He concluded: “Jest is awesome and I recommend you give it a solid look.” :slight_smile:

(kazag) #40

Vote for enzyme.

Simple to configure, well documented, clear API. Our stack is: mocha + chai + enzyme + redux mock store + sinon + nock.

(Dschinkel) #41

mocha + enzyme + chai-enzyme + jsdom is the way to go. Keeps testing simple, easier, less magic, cleaner, etc. Not a fan of Jest, too much magic, too much going on. It doesn’t fit well for TDD which is what I do. I try to stay away from big up front frameworks period…it just ads magic and complexity. Keep your tests and tools as simple as you can. I think enzyme has really found that balance.

I can’t say enough about enzyme. It’s simply made my life much easier and been a pleasure to use.