website/blog/2017-05-06-jest-20-delightful-testing-multi-project-runner.md
A few months ago we announced Jest 19 which came with major new features and was the biggest Jest release until today. Jest 20 has twice the amount of changes compared to the previous version, features a complete rewrite of the test runner, adds new testing APIs. The new release enables a new level of customization and configuration for projects all while making it effortless to upgrade. Beyond Painless JavaScript Testing, we believe Jest is now delivering a Delightful JavaScript Testing experience. Let's take a look at the best new features and changes in depth:
Until now, Jest could only operate in one project at a time. This is often cumbersome if you are working on many smaller projects that each have their own setup and configuration. With Jest 20, we rewrote the test runner completely to run many projects at the same time within a single instance of Jest, for example if you are working on a React frontend and a node.js backend. Here is a video of Jest running tests for React, Relay, Yarn and Jest all at the same time:
<!--truncate-->Jest is now collapsing the usage guide after the first test run to save vertical space in the terminal.
Further, we completely overhauled how the configuration system works inside of Jest. You can now pass any configuration option through the CLI to overwrite the ones specified in your configuration file. Along with that, we changed Jest to look for a jest.config.js file by default which means you are now able to define a Jest configuration using JavaScript as well as being able to configure it through package.json like before. Through the addition of all these new features, you are now able to combine Jest in more powerful ways than ever before. For example, if you would like to find out which tests Jest would run given a set of changed files from a commit across multiple projects in a monorepo, you can combine cli arguments like this now:
$ jest --projects projectA projectB --listTests --findRelatedTests projectA/banana.js projectB/kiwi.js
[
"projectA/banana.test.js",
"projectB/kiwi.test.js",
"projectB/pineapple.test.js",
]
This is especially useful for continuous integration (CI) systems where you may want to only run a subset of tests for Pull Requests to prevent Jest from running thousands of test files on every small change.
Finally, we are now properly mapping code coverage when using TypeScript and we are running code coverage for untested files in worker processes which yields significant speed ups for this feature.
We made a number of additions and improvements to the testing APIs which will help write more effective tests. We'd like to point out that all of these improvements were made entirely by community members!
expect(Promise(…)).resolves.toEqual(…). See documentation.n assertions: Along with the existing expect.assertions(n), the new expect.hasAssertions() can be used to ensure a test has at least one assertion.valid-expect rule was added to eslint-plugin-jest to ensure that an assertion is called after invoking expect. This will prevent mistakes like a stray expect(banana); with a missing assertion call.@jest-environment node|jsdom annotation to the doc-block comment of a test file to use a test environment different from the default for individual tests.Here is an example of all how all the new APIs together will make testing more delightful:
/**
* @jest-environment node
*/
test('compares apples and bananas', async () => {
expect.hasAssertions(); // Ensure this test has at least one assertion.
await expect(
Promise.resolve(Immutable.Map({apples: 1, bananas: 2})),
).resolves.toEqual(Immutable.Map({apples: 1, bananas: 3}));
expect('banana'); // valid-expect in eslint-plugin-jest will show an error.
});
This example will print a test failure similar to this:
As with every major release, we are making a number of breaking changes to make larger changes in the future possible and to push the testing experience to a new level. This time, we tried our best to only break APIs that we don't expect to affect the majority of Jest's users:
jest or expect objects. As such, we have removed many Jasmine features that aren't generally used in most codebases.--ci flag is specified. To overwrite this behavior, which is generally not recommended, the --updateSnapshot flag can be used.babel-polyfill automatically when using babel-jest which resulted in memory leaks inside of Jest. In most versions of node, it is not necessary to load babel-polyfill so we removed this auto-inclusion and instead changed Jest to only include regenerator-runtime by default, which is commonly used to support async/await in older versions of Node.js. If you need babel-polyfill, you can manually require it in your setup files.reporters configuration option. You can finally customize the output of Jest as well as integrate it with other tools by generating reports in formats such as XML. See documentation.Recently the Jest core team and other contributors started to talk more about Jest and the experience of working on Jest at conferences:
As always, this release couldn't have been possible without you, the JavaScript community. We are incredibly grateful that we get the opportunity to work on improving JavaScript testing together. If you'd like to contribute to Jest, please don't hesitate to reach out to us on GitHub or on Discord.