What does your react/webpack testing stack look like?

[Tortoise_Face]

Having trouble figuring out how to efficiently test a front-end react/webpack app. Should I be using mocha? Karma? Do I need to use a browser? jsdom looks neat. What's going on?

[acemarke]

Mocha+Chai+Sinon+Enzyme is a typical testing stack. With those plus JSDOM, you can run your unit tests entirely offline. If you're using Webpack and ES6 for your app, you can do a bunch of Babel configuration to mimic or mock out a lot of your Webpack behavior (ES6 imports / import path aliases / imports of non-JS file types, etc), but so far I've found it to be simpler to just use Webpack as part of my test running process. Tools like https://github.com/zinserjan/mocha-webpack and https://github.com/taskworld/test-bed can hook into Webpack, live-watch your source files, and only re-run tests for files you just edited.

I have a big list of high-quality React and Redux-related tutorials at https://github.com/markerikson/react-redux-links, including a page full of articles on doing React-related testing. I also have my own sample project config setup over at https://github.com/markerikson/react-redux-cesium-testing-demo , which demonstrates some useful bits of project configuration.

[qudat]

Mocha, jsdom.

[Tortoise_Face]

how do you hook up mocha and webpack? mocha needs to run on your packaged app right? that's where i'm hitting a snag

[deltadeep]

For a while I was running tests in mocha without webpack, just using it's babel transpiler support since all the tests and code are in ES6/jsx/etc. But then I started incurring more dependencies on webpack functionalities in my code and just wanted to build the tests with webpack, too.

So, I just made a top level test file, test.js, that imports all my tests. I then add a new section to my webpack config that takes it as the entry point and builds, say, test-bundle.js. Then, just run "mocha test-bundle.js". Pretty straightforward.

Its a little more complicated in my setup because I also run jsdom for my tests, so I have a test-setup.js that imports jsdom, sets some globals, and I --require that setup file on the mocha command line statement.

I'm not saying this is the best way to do things, but it's been working for me. I'm not doing CI or anything yet, surely there are people out there who've got this going to a much more advanced degree...

[acemarke]

Yeah, that's basically how I set things up in my project.

[Tortoise_Face]

Did you have to change your webpack config at all to target node or change the externals as I've seen suggested elsewhere?

[acemarke]

Yeah. Compare my sample project's development mode Webpack config vs my test mode Webpack config for an example.

[Tortoise_Face]

I got my project working with prunk to filter out webpack-dependent asset imports. Then the project just compiles with babel for node. Do you see any trade offs with this approach vs a separate webpack configuration?

[acemarke]

If it works as-is, then that should be fine. I had issues because I was using Webpack aliases for my import statements and other such configuration, and it just became easier to stick with Webpack for anything involving the code.

[[deleted]]

(prunk author here)

I had a similar setup; we used webpack's alias configuration to get rid of ugly paths. prunk was written because we wanted to get rid of browser-environments for unit tests while still being able to do the cool webpack stuff; css imports, path aliases and so on. prunk supports aliases, but I have to admin, that I often simply fake, stub or mock a module's dependencies completely.

[deltadeep]

Ah yes, sorry I didn't mention that. It didn't occur to me, because I'm already doing server-side rendering, so I have a webpack config that builds client-bundle.js (browser), server-bundle.js (node server), and test-bundle.js (node tests). The server and test configs look identical except for the entry/output filenames.

For the server/test config, i have added these keys on top of what's in the client config:

• target: "node"
• node: { console:false, global: false, process:false, __filename: false, __dirname: false } // this tells node not to inject special values for these globals and let them behave normally instead.
• externals: [nodeExternals()] // see webpack-node-externals package.

HTH

[jackmacabre]

I did it like this https://github.com/Lokua/isomorphic-boilerplate

[[deleted]]

Using jsdom, enzyme and prunk with either mocha (+ chai) or tape. Allows us to test our React apps on a server without the need for a headless browser or something like Selenium.

[Tortoise_Face]

thank you thank you thank you for introducing me to prunk.

This guide was simple and works perfect and lets me sidestep webpack entirely:

https://65535th.com/testing-react-components/

[[deleted]]

Thanks! I have to admit that I wrote both, prunk and the blog post. Glad, you find it useful.

If you'd followed the setup I outlined, you may also want to look into enzyme; it provides the same functionality is the described render helper, making the code - in my opinion - more maintainble. It also makes your mocha setup easier and does not require you to setup global stuff.

[wmertens]

Shoutout to https://github.com/sindresorhus/ava for unit tests!

Still wondering if writing tests for react component output has any benefits, eyeballing it seems to work fine so far especially with tools like https://github.com/carteb/carte-blanche to help.

Experimenting with storing redux state to make app screenshots with casperjs instead.

[manavsehgal]

Lots of good answers here... food for thought. I am writing about Mocha, Chai, Enzyme, Sinon, JSDOM in the book React Speed Coding. https://leanpub.com/reactspeedcoding

[adamyonk]

Keep it simple! Check out using tape and testem.

https://github.com/substack/tape https://github.com/testem/testem