š¤ 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
- I created two separate NX workspaces.
- 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.
- 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!
Top comments (0)