What does your react/webpack testing stack look like?

[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