Mocha: Jest

[Bamieh]

Jest is emerging as an alternative to mocha in many applications that use React and it recently surpassed mocha in github stars. Although github stars is not the measuring stick, I believe that we should be addressing the elephant in the room.

At the time of writing this, there are over half a million react project tagged on github. I believe jest is gaining popularity in the react community due to the following:

• Snapshot testing
• Coverage built in
• A bold statement about who is using Jest, encouraging new comers.
• Out of the box configurations
• Super powerful documentation

Snapshot testing

Jest popularized "snapshot testing" for react developers:

Capture snapshots of React trees or other serializable values to simplify testing and to analyze how state changes over time.

The community created many tools for snapshot testing for mocha. We can either adopt a project and put it under mocha, write our own, or just document how snapshot testing can be used with mocha on our website.

Easier Configurations

Introduce presets (like babel presets), this way a developer can use a "react preset" that includes coverage, snapshot testing, chai, etc. Or create their own preset for their OSS or their company. Also extendable rc/json configs come to mind, and more default configs.

Documentation

The github wiki is very unappealing for users, maybe we can use something like Docusaurus for awesome documentation, or just extend the current website. Also we can provide more examples on common scenarios and guides (usage with es6, babel, async examples, snapshot testing, etc)

Encouraging new comers

Mocha is very widely adopted, almost every other person that ever used javascript knows mocha, we can use this to encourage new comers to join by highlighting some of those facts about mocha. Usually developers work in teams or OSS, and wide community adoption is a very good reason to choose an OSS as it proves stability, maintainability and availability of examples and help.

Coverage

Mocha integrates beautifully with coverage tools such as nyc. As coverage is almost always needed in projects along side testing, we can highlight how to use mocha with nyc for example, it is as simple as

$ nyc mocha

Also presets can embrace setting up coverage tools.

Highlight mocha's power

I personally always favor mocha for this specific reason: "you can never go wrong with mocha". Mocha is very extensible, you can customize it to work exactly the way you need without hacking anything, everything from the reporter to how and when the tests run is configurable with code or flags or some other sort (I am even using it for e2e native testing and integration testing). I believe it would be nice to highlight those features in a modern way rather than a text list.

CC @mochajs/core

[boneskull]

This deserves a more thoughtful reply, as it brings up several different important issues--some about open-source software, and others about Mocha's scope and place in the ecosystem. So, I'll respond more thoroughly sometime this week (and may even write a blog post, because this is important).

If I can summarize my thoughts for now:

1. I firmly reject the idea that Jest's popularity is a problem for this project or its future.
2. Even if I thought Mocha should compete with Jest, Mocha cannot compete with Jest.
3. We must be exceedingly choosy about what features we add to core.
4. There are some great ideas for documentation here--"recipes" are needed.

To each of the above, I'll reply at length soon. I don't think there's really anything actionable here except to create specific issues, but I'll leave this open for now.

[Bamieh]

@boneskull I generally agree with all what you've wrote.

I do not believe that Jest is a problem for mocha, instead I think it is beneficial in some sorts for us and the community in general. Metaphorically speaking, Jest is bringing more cake to the table instead of slicing from mocha's cake.

Jest did succeed to attract a large number of developers to embrace it, hence I wrote this to share my thoughts on how they did that, maybe we can use those ideas to make it easier for those who want to use mocha but want some features in jest, to be easily able to find good documentation and examples on how to do so (ie snapshot testing) from within mocha.

I opened this issue to bring it to discussion and hopefully open a few action items based on that.

[Munter]

Jest is certainly in no way a problem for Mocha, or vice versa. I had a nice conversation with @cpojer a year or so ago at JSConf.eu, where he mentioned that he wants to see all test tools succeed and help each other out. I just haven't had the energy yet to follow up on any collaboration that might be possible between the two projects.

I know that @sunesimonsen, @papandreou et al., have been working on a lot of things in unexpected that have started hitting the limits of what Mocha and Jest expose in terms of testing hooks, and would certainly love to give input on how both projects can improve the assertion ecosystem with for example hooks. If I recall correctly, snapshot testing can actually be moved into assertion-land with the right hooks. It's just the politics part of having two projects coordinate to add new stuff at the same time that has scared them away :)

[cpojer]

Hey everyone! The premise of this issue really is off-putting to me. I do not consider that Jest and Mocha are competing, and they wouldn't compete on equal footing if they were. I do not believe that for one to succeed the other one needs to suffer or being talked down upon. The feature set of both is somewhat orthogonal to each other, as is the focus of both: Mocha is a test runner while Jest considers itself an extensible platform for basic JavaScript tools and especially testing tools. Jest provides a test runner, test library (a fork of jasmine), an assertion library expect, a snapshot feature and basic JS tooling. It just happens that there is a large overlap between Mocha and Jest in the test runner space. I do want to point out that in your original assessment, one reason why people use Jest is for performance reasons. If you do love mocha, and you want all the test runner features and perf features from Jest at the same time, check out jest-runner-mocha which allows you to use Mocha together with Jest and Jest's watch mode.

If you'd like to adopt snapshot functionality, the jest-snapshot package is easy to re-use. You can embed it into mocha and if it doesn't do something you'd like it to do, please send us PRs!

If you'd like to find out more about Jest as a platform please watch @rogeliog's talk. He also mentions a number of useful packages that you can use to do things like parallelization using jest-worker etc. Happy to help out with more context and also happy to have a video chat to discuss more things. If you are in London, we are hosting a Jest Summit this Thursday and Friday at the Facebook office. Shoot me an email to [email protected] if you want to join us.

@Munter hoping to hang out at jsconf again this year!

[boneskull]

@cpojer Thanks for weighing in.

Developers want to compare similar frameworks (of any kind). It's unfortunate, as this tends to do little more than accumulate clicks and sew division. Even if there's a significant difference in project scope, articles will still get written about why you should choose x over y.

To that end, even though we both agree this issue is off-putting, it's also obviously on people's minds. It's not something we'll ever be free of, as long as there is overlap in use cases.

The best we can do is highlight the differences in scope and remind people that this isn't a zero-sum game.

[cpojer]

@boneskull I think you are right in the abstract sense that these comparisons are happening but I'd be curious to understand the concrete list of articles that you find that are inaccurate or are promoting "us vs. them" attitudes. I'll do my best to correct people that aren't being objective.

[boneskull]

@cpojer Happily I don’t have any for Mocha and Jest! But it could be Mocha and Tap, or Angular and React, or Webpack and Parcel, or TypeScript and Flow...

[Bamieh]

@cpojer I wrote this with the intent to see what Jest is doing in terms of community reach and ease of use so we can learn from here in mocha (ie. improved documentation, more examples of common features, and improved out of the box configurations).

I do agree with the context of what is being said here regarding "mocha vs Jest", but again the examples of such comparisons are countless and they exist in many flavors, from "migrating from mocha to jest" to "picking jest over mocha". Literally just opening the latest release notes of jest the first lines of the notes are:

After converting from Mocha to Jest 23 Beta, Webpack saw their total test suite time reduced 6x from over 13 minutes to 2 minutes 20 seconds. #blazingmeansgood

[boneskull]

IMO it’s not a mystery how to provide great docs and defaults. Mocha doesn’t have them because of a lack of resources.

[boneskull]

@Bamieh What I was talking about was inflammatory articles where x framework gets trashed, not necessarily tutorials or objective performance measures.

[Bamieh]

Closing this as part of cleaning. Thanks everyone for the input, I'll open issues later on with related tasks based on your input ❤️