Every React project is a little different. This can make choosing the right testing setup difficult.
Both Jest and Mocha seem to be popular within the React community. There are tons of folks using Jest, though others seem to prefer Mocha (for example, the Enzyme docs and examples use Mocha). So which one should you choose, and does it even matter?
I recently started a large full-stack project using TypeScript, and we put some effort into researching which testing framework to use. In this post, I’ll discuss what we learned and highlight a few scenarios that may lend themselves to one over the other.
Jest is a testing framework authored by Facebook.
Update: my post originally stated that Jest was designed specifically to be used with React. I’ve since updated it based on the below tweet from Christoph Pojer.
I’m glad he responded to my post. My original description of Jest was perhaps overly narrow and didn’t capture the general flexibility that the Jest authors intended.
The Jest docs clarify this by stating
This is something that I wasn’t aware of.
After starting out as open-source, Jest went through a bit of a dormant phase where Facebook did not put much work into it. This created some negative feelings toward it within the development community. To their credit, Facebook has since corrected this issue. They’ve poured a ton of work into Jest over the past year, adding new features and improvements.
The revamping process started with the release of Version 15 late last year. Here’s a peek at their current roadmap.
Strengths of Jest
The biggest advantage of using Jest is that it works out of the box with minimal setup or configuration. Much of this is because it comes with an assertion library and mocking support. The tests are written in BDD style, similar to any other modern testing library. You can literally just put your tests inside of a directory called
__tests__ or name them with a
.test.js extension, then run
jest and it works. That is pretty sweet.
Jest also supports snapshot testing, which can be really handy for preventing accidental UI regressions when doing React development. These tests record snapshots of rendered component structure and compare them to future renderings. When they don’t match, your test fails, indicating that something has changed. You can easily tell Jest to update the snapshot if this change is expected (e.g. for a newly added feature).
Weaknesses of Jest
It has less tooling and library support available compared to more mature libraries (like Mocha). Sometimes this type of tooling can be really handy, like the ability to run and debug your tests in an IDE like WebStorm. Until recently, WebStorm didn’t even support running Jest tests. This just changed with the latest WebStorm release, but it still doesn’t support interactively stepping through your tests using the debugger.
Due to its young age, it may also be more difficult to use Jest across the board for larger projects that utilize different types of testing. For example, we recently set up Nightmare for integration testing. It is easy to run Nightmare integration tests with Mocha, and the docs have nice examples. We could have probably gotten Nightmare working with Jest without much work, but this is an example of the friction you might experience if you want to integrate Jest across your project stack.
Strengths of Mocha
Because of its maturity and widespread adoption, there is a lot of tooling built up around Mocha. To go back to the earlier WebStorm example, it’s been possible to run and debug Mocha tests in WebStorm for some time.
Lastly, the Mocha community is large, and there is a lot of support available in the form of videos, blog posts, and libraries.
Weaknesses of Mocha
Mocha’s main weakness is that it requires more configuration.
You have to explicitly choose and install an assertion library, mocking framework, etc. If you value this flexibility, that can be great, but if you don’t, it can be frustrating.
You can use snapshot testing with Mocha, but it’s not as easy to integrate. Like most things with Mocha, there is a library called chai-jest-snapshot that helps integrate this functionality However, it’s yet another thing to set up.
So which testing framework should you choose? I don’t think there’s a bad choice since you can make either work with some amount of effort. However, given the recent investments that Facebook has been making and the general positive response from the React community, I would recommend giving Jest a shot, unless:
- You have identified parts of your tool chain that don’t support Jest (e.g., WebStorm debugger example from above)
- You have a large interest in future flexibility–being able to swap out assertion, mocking, other test libraries, etc.
We chose Mocha–largely because we had a lot of interest in being able to use the WebStorm debugger from time to time. However, I think we could have also chosen Jest and been just fine.
TL;DR is Mocha understands the single responsibility principle and separation of concerns and Jest doesn’t because Facebook wants you to drink their Koolaid at work and in your social life.
That’s an awfully cynical view. There’s something to be said for something that ships with batteries included; if we had to assemble operating systems in 2017 to use our computers, we’d all go mad.
In the library world library vs framework it’s easy to solve the popular batteries included scenarios via scaffolding and example projects. Lots of Yeoman templates exist for using mocha, chai, and sinon, and ready-to-clone sample projects on GitHub too.
Not generally a fan of the example project. They tend to drop a giant package.json full of unexplained dependencies into a developer’s lap, expecting them to understand how everything is pieced together without giving them a guide—and that’s if they’re actually completely up-to-date instead of just slightly too old to be useful.
Contrast this with a well-maintained distribution containing everything most people need. It can potentially be painful if you want to extend it on a path that’s not well-traveled, granted, but everything works out of the box and all the documentation is in one place.
WebStorm debugger support seems to be there now?
Thanks for the amazing post Matt, I decided to use chai-jest-snapshot because I already had Mocha configured, I don’t think configuring things in Mocha is that hard, but It’s just my opinion, jest looks amazing for just getting working out of the box though.
Thanks for your post, as I started reading your post I was expecting you to talk about testing Typescript code. Nowadays many companies are switching to Typescript and I really love it and trying to find some best practices. I hope you write a post about it or if you can help me around this.
Have you ever compared the performance of the libraries?
I’ve done a few tests and Jest seems to be way slower than Mocha. It might be something I did wrong, but that’s the main reason that makes me choose for mocha every new project :)
Comments are closed.