DEV Community

Dmitry A. Efimenko
Dmitry A. Efimenko

Posted on • Originally published at Medium on

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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!

Top comments (0)