Going from Jest to Karma/Jasmine in an NX monorepo

🤔 I honestly don’t understand the hype around Jest.

People often cite the following for switching from Karma/Jasmine to Jest:

#1 Jest has better performance

#2 Jest is easier to configure

#3 Jest has easier CI/CD integration

#4 Jest has a nicer reporting format

Here’s what I think about each of these bullet points:

#1 Jest has better performance

There is some merit to this statement. Jest does NOT run unit tests in a browser. Therefore Jest does not have to spend time starting a browser, which takes a few seconds. Unit tests might be faster because they run in this “mocked” browser environment.

There are also random claims without any proof around the internet that Jest is 2 to 3 times faster than Jasmine. Maybe. Although there’s this open issue on Jest with a ton of upvotes (at the moment of writing this blog): “Jest performance is at best 2x slower than Jasmine, in our case 7x slower”. So…

#2 Jest is easier to configure

Again, maybe. I haven’t personally run into any issues configuring a project to use Karma. Usually, the tooling (NX or Angular/CLI) does the whole job! Then modifying the configuration is a piece of cake — as I’ll show toward the end of the article.

#3 Jest has easier CI/CD integration

This is a matter of configuration. All that is needed is to provide a configuration to run the unit tests in CI/CD via a headless browser. It’s really not difficult, especially with the countless resources online showing how to.

#4 Jest has a nicer reporting format

This is, again, a matter of configuration. Don’t like the default reporter that comes out of the box for an Angular project? No problem, use a different one! I’ll show what I do for each of my projects in the section “ Configuring Karma Reporter ” below.

👍 Why I like Karma/Jasmine

I really don’t want to make this article into a “Jest vs Karma/Jasmine” thing. Like Jest? Fine! Use it! And no need to continue reading this!

Personally, I like Karma/Jasmine. Here are a couple of reasons why:

Confidence

In my opinion, even if Jest was faster than Jasmine, I do not think that is reason enough to switch to Jest.

In contrast to Jest, Karma runs unit tests in the real browser — the same environment where the project that was built will run. This ensures that the unit tests run the code in the real environment. Thus, a developer gains better confidence in the quality of the code. This is worth a lot!

Stability

I have recently run into an issue related to Jest, which causes the unit tests to error out. This completely blocked me and was the tipping point for me to convert my project to Karma/Jasmine and write this article.

Without further ado, here are the steps I took to do the conversion.

➡️ Converting Jest to Karma/Jasmine

1. I created two separate NX workspaces.
2. I added an Angular library to both of them. However, one was configured to have Jest as a test runner and another one had a Karma/Jasmine test runner.
3. Then I looked at the differences and applied them to my project!

Here are all the files that got changed for one project:

Uninstall Jest-related dependencies from the project

npm uninstall @nrwl/jest @types/jest jest jest-environment-jsdom jest-preset-angular ts-jest

Install Karma/Jasmine dependencies

npm install -D @types/jasmine@4.0.0 jasmine-core@4.2.0 jasmine-spec-reporter@7.0.0 karma@6.4.0 karma-chrome-launcher@3.1.0 karma-coverage@2.2.0 karma-jasmine@5.1.0 karma-jasmine-html-reporter@2.0.0

Notice, that I’m installing specific versions of the packages. I need to make sure that all of these packages are compatible with each other. I know that these packages are the right versions because these were the versions installed by Nx. Let the other folks figure out the right version combination 😉.

Adjust files in the root directory

nx.json — update unitTestRunner to “karma” and point things to “karma.conf.js” instead of jest.config.js

karma.conf.js — a new file copied from the fresh NX workspace

Adjust files in each individual project

/projects/myProject/jest.config.ts — removed

/projects/myProject/src/test-setup.ts — removed

/projects/myProject/karma.conf.js — copied from the fresh NX workspace

/projects/myProject/project.json — update targets.test.executor to be @angular-devkit/build-angular:karma and update related options (copy from fresh NX workspace and update paths)

tsconfig.lib.json — update the exclude property (copy from fresh NX workspace)

tsconfig.lib.prod.json — modify this file if your project is publishable. Remove exclude property.

tsconfig.spec.json — remove files and compilerOptions.module properties. Adjust compilerOptions.types property.

All-in-all — not that many changes. Somebody should write a schematic to do this automatically though😁.

At this point, the configuration is exactly the same as in a fresh Nx workspace. Now, time to improve!

⚙️ Configuring the Karma Reporter

In this section, it will be apparent to see how easy it is to work with the Karma configuration and how to improve the reporter.

By default, Karma is configured to use two reporters: ['progress', 'kjhtml'] .

The kjhtml reporter is the reporter used in the browser. I usually remove it. I also switch the chrome browser option to ChromeHeadless option so that the browser window does not open altogether.

The process reporter is the default reporter used in the terminal. I don’t quite like how it prints out things. I usually switch it out to the karma-mocha-reporter .

Install the mocha reporter

npm i -D karma-mocha-reporter

Update the karma.config.js

That’s it!

📖 Summary

I mostly wrote this article for my own sake — in case I’ll need to do this again in the future. But I hope it’ll help fellow programmers who face similar dilemmas too.

👏 Special thanks to Ana Boca for reviewing this article!