Thanks a lot for this, I really appreciate! This video would greatly help, specially when starting a new Angular project and deciding which test framework to use.
@@RainerHahnekamp I'll pick Jest since it's better suited for unit test scenarios; If we really need to simulate the whole browser, we better go with Cypress component testing.
@@MrAnother67 sorry, that "old" was meant as a joke. Forgot to add the proper smiley. Cypress component testing definitely, no doubt about that. And if comes to Jasmine/Jest, I have my personal preference that I articulated in the video, but both are fine.
Thank you so much for this informative video! Helped me gained insight into testing in Angular, from the Angular builder, to the transpilation from ESM to CJS/MJS which is needed for Jest to run in NodeJS via jsdom. I recently migrated my company's legacy Angular project to v16 and was excited to try out Jest. But unfortunately the experimental Angular Builder for Jest is having issues when it comes to .SCSS @import and @use rules in my component's stylesheets. Also it seems that existing tests written using Jasmine's mocking facilities (spyOn, createSpy, createSpyObj, etc) are not compatible. In any case, would you have any upcoming videos about the integration of Vite (for the development server) and ESBuild for the production bundling/building in Angular? I would love to learn about how they work behind the scene!
Hi, yeah you are right. So the major difference between Jasmine and Jest is the mocking part. This is something where you definitely have to rewrite some things. About esbuild and vite, let's see how it goes. As soon as Angular 17 arrives, I'll recheck on the status of Jest and maybe come up with an updated video. Happy you liked it so far. Cheers!
Thank you very much as well. By the way, angular 17 didn’t improve the jest support. It is almost on the same level as in 16. So if you ask me now, which library I would choose, it would be Jasmine
This is a excellent slow paced video. What would you suggest for angular 17 project seeing the way things angular team laid out? My concern is mostly around the lines of official docs for jest not coming from angular docs website. If my junior team even wants to learn stuff, they'll diverge from official docs where they are learning most of things in well thought way.
Hi, thanks. As it stands at the moment, I would pick Jasmine. There was neglectable progress for Jest support in Angular 17 and the official docs say that the Angular team wants to focus on the transition from Karma to Web Test Runner first. If you can Jasmine, if you plan to use Nx, then you don't have a choice. Nx only supports Jest.
Ok, so I was in charge of my teams effort to migrate from Karma/Jasmine to Jest while still using ng14. Everything that I read indicated than Jest should be faster, but I was seeing that jest is actually quite a bit slower. Particularly while running in a pipeline. This makes so much sense! Thanks!
Hey Rainer, thanks for this great video - This clarified a lot for me! Is there an easy way to opt-in from an Nx project to the built-in jest support in Angular?
Great to hear. At the moment, the official Jest support is experimental. So everything I can say about the future is just speculation. But since the code of your tests doesn't change, I would expect that Nx replaces it under the hood. As a consequence, you won't have to do anything (except enabling it)
@@RainerHahnekampI was about to ask the same question. I have a huge Angular project with Nx and running the tests using the Nx's Jest runner is terribly slow, with your video now I understand why. Do you know how can I use the experimental Angular's Jest runner instead of the Nx one?
@@santiagof4 How urgently is it and are you on Angular 16? We are currently conducting some tests with that experimental mode. It is not ready for production. That being said. I've updated the GitHub Repo with an nx version which is using the Angular CLI builder instead the one from Jest. You can find the commit with all the necessary changes: github.com/rainerhahnekamp/angular-testing-status/commit/ee8acfad61ca96504d7b1bcb1ebe787207a559c7 Let me know if it works for you.
Hi Rainer, this is a very helpful video. I have an Angular 16 project using Jest (the old way i.e. with the preload). I have tried to change to using @angular-devkit/build-angular:jest but my tests all fail. There seems to be an issue with an @import "variables.scss" import in my component scss files. There is nothing obvious to indicate that the build failed although there aren't any .mjs files in the disct/test-out folder and then I get loads of this error: ✘ [ERROR] Can't find stylesheet to import.
Hi, yeah, that's the problem when something is marked as experimental. You can't expect that everything works. Do you maybe have the option to switch back to Jasmine? At the moment, that ones gets most attention from the Angular team.
@@RainerHahnekampwe have the tests running with jest and have bought into using testing library. The tests just run a bit slow. 320 tests in about 2 minutes. But if we focus on an individual test suit or test then the performance is ok. Thanks for the reply.
hey, thank you - very well explained :) But I have one question. You said that jest works with CommonJS and if we have some files in ES module we need to compile them to CommonJS. But in 14:31 you shows option "transformIgnorePatterns" and said that thanks to that option .mjs (ES module) files will not be transpiled. Im little confused because first you says that ES modules needs to be transpiled to CommonJs, and then that ES modules files will be not transpiled 🤔🤔 Could you please explain it a bit more, because I must have misunderstood something
Hi, yes, the missing ESM support WAS an issue (past tense). In 12:43, I mention that Jest has slowly started to support ESM, and all the testing libraries run already in that experimental ESM mode. That's why the transformIgnorePattern actually works. Is it clearer now?
What do you think about Vitest for Angular, we moved our plain JS tests from Jest to Vitest due to constant issues with ESM modules and need to do lot of config for ESM transformation. Vitest has native ESM support. It was a breeze getting it up and running.
@@VinitNeogi If you manage to integrate vitest with less pain than jest: congratulations. Best choice you could make. Vitest is also 100% compatible to jest but blazingly fast. In terms of performance, I see a lot of potential for Angular 's integration as it also uses (as vitest) esbuild under the hood. Are you using analog for the vitest integration or did you all do it by yourself?
@@RainerHahnekamp I migrated plain tyepscript tests (not Angular) from jest to Vitest, apologies if I wasn't clear. Only followed vitest docs, hardly there was any config required. I haven't tried to use vitest with Angular yet, but I should. Can look into analog's implementation for reference. Agree on the esbuild part, should help with performance.
By the way, I have a quick question : what do you think about Shai (HiRez) method for testing the Angular components in isolation, meaning not using the test "declarations" but rather use the "providers" array that allows to treat the component like any injected class ?
Yeah, so I haven't talked to Shai personally to understand the context. When you treat a component as a service, you are not communicating with it via the DOM but call event handlers and assert against properties, etc. directly. I have the impression that over the years, we came to a broad consensus (not just in Angular) to test components via the DOM. Just look at the testing library which takes quite an opinionated approach or the new rise of E2E frameworks that also provide component testing. Classic unit testing with services is something I usually do when a significant amount of logic is involved. In general, I try to extract the logic into the services then. As long as I have simple services, I try to include them in a higher level test. So a test of a component where the actual service is also involved. The biggest obstacles with Dom based tests is that they are quite slow and much harder to write. Here again, frameworks like Spectator, testing library, cypress CT come in quite useful. As far as to Shari's approach, I can't go into details. I've seen his talks and can say that he has a profound understanding and experience what testing is all about and what issues you are facing.
@@RainerHahnekamp thanks for your answer here ! Shai's approach is indeed not to go for DOM, and go isolation. I like this idea and it does in my opinion help with writing the mocks of dependencies. I think that it's not complete approach and should be mixed with some e2e testing. Anyway, always a pleasure to have different point of view. Cheers ! 🙂
@@AlainBoudard Yeah so E2E is something which was out of scope for this video (Angular CLi doesn't provide E2E integration). But it is a critical part for testing. In short, we do testing of logic with non-DOM tests, second layer are the DOM tests with Testing Library, Spectator or Cypress CT and then you have E2E which you usually can rely on a Webdriver-based framework or you go with Cypress/Playwright.
Hi, so my project is Angular 16 and I don't really see the need to update it. Angular 17 didn't actually change that much in terms of testing. We still have Karma and the Jest support is still experimental.
@@RainerHahnekamp I also don't see any advantages in switching to Jest, but the large corporations that pay my salary and use Jest, so I have to study Angular with Jest, 🥲🥲🥲🥲
For the 'testing-cli-jest-native' project, can you make a copy of the 'app.component.spec.ts' file into a sub-folder, fix the import, and then run the tests again? I get an error when there are .spec.ts files that have the exact same name but in different folders. "Two output files share the same path but have different contents" All the output files are being flattened into the 'dist\test-out' folder.
Hi, I wouldn't bother too much about this moment. This is an experimental version. It is not meant to be used in "real life". The Angular team wants to find out if their approach is the right one and feasible. You will see improvements in the "developer experience area" hopefully quite soon. I can't tell you how Jest support in Angular 17 will be, but maybe it will be much better than in 16.
Thank you@@RainerHahnekamp I did comment on a relevant issue on GitHub. The issue is being tracked. I agree that it's probably best wait until ng17 to try this again, since its experimental.
But Reinier, I only have about 60 tests so far, not 10 thousand like the Facebook developers have. Jest gives me nothing but a burden to upgrade because it is the new official path :-(
Hi Marc, if I would do this video now, I would not recommend Jest anymore. I expected that Jest will be available as developer preview in Angular 17 but the Angular team shifted its main focus towards the migration from Jasmine from Webtest Runner.
@@VankataKisyov NO. We see that the official support for Web Test Runner and Jest didn't get so much attention from the Angular team and the situation in 2024 is the same. If you run right now on Jasmine, stay where you are, if you are on Jest and have no issues, also stay. If you have issues with Jest consider a switch to Jasmine. In my video I said I would pick Jest because it looked like we official support already in Angular 17. As it stands no, it will probably be in 2025.
so jest is not supported by angular, and karma is deprecated .... so what is currently supported by angular? suppose i want to use testing framework supported by angular today what do i do if not jest or karma?
As I was saying at the end, given Jest's adoption in the JavaScript ecosystem, I would go with that one. You might be on a bumpy road with its community support at the moment, but once it is officially supported by Angular, I'm very optimistic that it will be a joy (also in terms of build performance). If you want to play it safe, go with Karma/Jasmine. The transition from Karma to Web Test Runner will be done by migrations. Since Web Test Runner and Karma are just the runners, the code for your tests will not change. It is and will be Jasmine. I would strongy discourage you from using any other framework than Jest or Jasmine. The integration into Angular is not a trivial task. Don't do it. You could go with Vitest as an alternative. But then, you would have to use Analog on top of Angular. That's an option.
@@RainerHahnekamp thank you for your explanation and help, one last question ... Will the tests written in jasmine not run with jest? I'm under the impression that jest is built on top of jasmine so should the tests already written in jasmine still work correctly with jest? Thank you again
There is a jasmine runner in Jest but I’m not sure if that one is still available in the latest versions. Jest emancipated itself from jasmine over the years. Especially in the area of mocking, spying, the commands are quite different. In general, it is easy to migrate from jasmine to jest but you have to manually change some of your test code
Karma does still exist, because they are still working on the migration to Web Test Runner. To be fair, one has to say that Jasmine/Karma doesn't have any issues - it is running fine - so they don't see this task as main priority. Jest will come after Web Test Runner is done and Jasmine will stay (as I said in the video). Btw, in th meantime, I would use Jasmine for a new project. Given the troubles we have with Jest/Angular and the pace of the migrations, I am afraid official Jest support is something we get in 2025. Last year, I had the impression that Jest will already be available in Angular 17.
Yeah, so I decided not to cover Cypress or any other E2E testing tool in this video/article since it is about Jasmine and its alternatives. Maybe I do a reboot for 2024. Would probably include it there.
![[UA] NAVI vs MOUZ | BO5 | IEM Rio 2024](http://i.ytimg.com/vi/CMBYk0cbGoA/mqdefault.jpg)
Superb content for angular testing, very informative and well-structured video
Thanks, with all that positive feedback, I might come up with a 2024 edition :)
Thanks a lot for this, I really appreciate! This video would greatly help, specially when starting a new Angular project and deciding which test framework to use.
Thanks, which one did you pick?
@@RainerHahnekamp I'll pick Jest since it's better suited for unit test scenarios; If we really need to simulate the whole browser, we better go with Cypress component testing.
@@MrAnother67 Ah, so the "old" Cypress & Jest combo :).
@@RainerHahnekamp Didn't know it's the "old" one... What's your recommendation?
@@MrAnother67 sorry, that "old" was meant as a joke. Forgot to add the proper smiley.
Cypress component testing definitely, no doubt about that. And if comes to Jasmine/Jest, I have my personal preference that I articulated in the video, but both are fine.
Wow, Thank you Rainer, it was a great help!
You are very welcome Jonatas
fantastic explanation, thank you very much!
Great to hear. You are welcome!
Thank you so much for this informative video! Helped me gained insight into testing in Angular, from the Angular builder, to the transpilation from ESM to CJS/MJS which is needed for Jest to run in NodeJS via jsdom.
I recently migrated my company's legacy Angular project to v16 and was excited to try out Jest. But unfortunately the experimental Angular Builder for Jest is having issues when it comes to .SCSS @import and @use rules in my component's stylesheets. Also it seems that existing tests written using Jasmine's mocking facilities (spyOn, createSpy, createSpyObj, etc) are not compatible.
In any case, would you have any upcoming videos about the integration of Vite (for the development server) and ESBuild for the production bundling/building in Angular? I would love to learn about how they work behind the scene!
Hi, yeah you are right. So the major difference between Jasmine and Jest is the mocking part. This is something where you definitely have to rewrite some things.
About esbuild and vite, let's see how it goes. As soon as Angular 17 arrives, I'll recheck on the status of Jest and maybe come up with an updated video.
Happy you liked it so far.
Cheers!
Amazing Explanation!
Thanks 👍
Great explanation! Kudos tu you.
Thank you very much as well. By the way, angular 17 didn’t improve the jest support. It is almost on the same level as in 16.
So if you ask me now, which library I would choose, it would be Jasmine
Thank you very much for your comment regarding your preference right now . We are starting now and I would
prefer Jasmine 🙂.
This is a excellent slow paced video. What would you suggest for angular 17 project seeing the way things angular team laid out? My concern is mostly around the lines of official docs for jest not coming from angular docs website. If my junior team even wants to learn stuff, they'll diverge from official docs where they are learning most of things in well thought way.
Hi, thanks. As it stands at the moment, I would pick Jasmine. There was neglectable progress for Jest support in Angular 17 and the official docs say that the Angular team wants to focus on the transition from Karma to Web Test Runner first.
If you can Jasmine, if you plan to use Nx, then you don't have a choice. Nx only supports Jest.
Thanks for the presentation Rainer !
I love the insights on the Jest integration on the internals of angular runners.
You are welcome. It is definitely a good idea that Angular is finally integrating Jest.
Very helpful video, thank you
You're welcome
It was very usefull information for me. Thanks a lot)
You are very welcome!
Thank you so much!
Thanks a well Eduardo
Ok, so I was in charge of my teams effort to migrate from Karma/Jasmine to Jest while still using ng14. Everything that I read indicated than Jest should be faster, but I was seeing that jest is actually quite a bit slower. Particularly while running in a pipeline. This makes so much sense! Thanks!
Yeah, so the statement that Jest is faster comes from old times and maybe from other frameworks where ESM was not a topic.
Hey Rainer, thanks for this great video - This clarified a lot for me! Is there an easy way to opt-in from an Nx project to the built-in jest support in Angular?
Great to hear. At the moment, the official Jest support is experimental. So everything I can say about the future is just speculation. But since the code of your tests doesn't change, I would expect that Nx replaces it under the hood. As a consequence, you won't have to do anything (except enabling it)
@@RainerHahnekampI was about to ask the same question. I have a huge Angular project with Nx and running the tests using the Nx's Jest runner is terribly slow, with your video now I understand why. Do you know how can I use the experimental Angular's Jest runner instead of the Nx one?
@@santiagof4 How urgently is it and are you on Angular 16? We are currently conducting some tests with that experimental mode. It is not ready for production.
That being said. I've updated the GitHub Repo with an nx version which is using the Angular CLI builder instead the one from Jest. You can find the commit with all the necessary changes: github.com/rainerhahnekamp/angular-testing-status/commit/ee8acfad61ca96504d7b1bcb1ebe787207a559c7
Let me know if it works for you.
Hi Rainer, this is a very helpful video. I have an Angular 16 project using Jest (the old way i.e. with the preload). I have tried to change to using @angular-devkit/build-angular:jest but my tests all fail. There seems to be an issue with an @import "variables.scss" import in my component scss files. There is nothing obvious to indicate that the build failed although there aren't any .mjs files in the disct/test-out folder and then I get loads of this error: ✘ [ERROR] Can't find stylesheet to import.
Hi, yeah, that's the problem when something is marked as experimental. You can't expect that everything works. Do you maybe have the option to switch back to Jasmine? At the moment, that ones gets most attention from the Angular team.
@@RainerHahnekampwe have the tests running with jest and have bought into using testing library. The tests just run a bit slow. 320 tests in about 2 minutes. But if we focus on an individual test suit or test then the performance is ok. Thanks for the reply.
hey, thank you - very well explained :) But I have one question. You said that jest works with CommonJS and if we have some files in ES module we need to compile them to CommonJS. But in 14:31 you shows option "transformIgnorePatterns" and said that thanks to that option .mjs (ES module) files will not be transpiled. Im little confused because first you says that ES modules needs to be transpiled to CommonJs, and then that ES modules files will be not transpiled 🤔🤔
Could you please explain it a bit more, because I must have misunderstood something
Hi, yes, the missing ESM support WAS an issue (past tense). In 12:43, I mention that Jest has slowly started to support ESM, and all the testing libraries run already in that experimental ESM mode. That's why the transformIgnorePattern actually works. Is it clearer now?
@@RainerHahnekamp yup, thank you 👍🙂
What do you think about Vitest for Angular, we moved our plain JS tests from Jest to Vitest due to constant issues with ESM modules and need to do lot of config for ESM transformation. Vitest has native ESM support. It was a breeze getting it up and running.
@@VinitNeogi If you manage to integrate vitest with less pain than jest: congratulations. Best choice you could make.
Vitest is also 100% compatible to jest but blazingly fast. In terms of performance, I see a lot of potential for Angular 's integration as it also uses (as vitest) esbuild under the hood.
Are you using analog for the vitest integration or did you all do it by yourself?
@@RainerHahnekamp I migrated plain tyepscript tests (not Angular) from jest to Vitest, apologies if I wasn't clear. Only followed vitest docs, hardly there was any config required.
I haven't tried to use vitest with Angular yet, but I should. Can look into analog's implementation for reference.
Agree on the esbuild part, should help with performance.
By the way, I have a quick question : what do you think about Shai (HiRez) method for testing the Angular components in isolation, meaning not using the test "declarations" but rather use the "providers" array that allows to treat the component like any injected class ?
Yeah, so I haven't talked to Shai personally to understand the context.
When you treat a component as a service, you are not communicating with it via the DOM but call event handlers and assert against properties, etc. directly.
I have the impression that over the years, we came to a broad consensus (not just in Angular) to test components via the DOM. Just look at the testing library which takes quite an opinionated approach or the new rise of E2E frameworks that also provide component testing.
Classic unit testing with services is something I usually do when a significant amount of logic is involved. In general, I try to extract the logic into the services then.
As long as I have simple services, I try to include them in a higher level test. So a test of a component where the actual service is also involved.
The biggest obstacles with Dom based tests is that they are quite slow and much harder to write. Here again, frameworks like Spectator, testing library, cypress CT come in quite useful.
As far as to Shari's approach, I can't go into details. I've seen his talks and can say that he has a profound understanding and experience what testing is all about and what issues you are facing.
@@RainerHahnekamp thanks for your answer here !
Shai's approach is indeed not to go for DOM, and go isolation. I like this idea and it does in my opinion help with writing the mocks of dependencies.
I think that it's not complete approach and should be mixed with some e2e testing.
Anyway, always a pleasure to have different point of view.
Cheers ! 🙂
@@AlainBoudard Yeah so E2E is something which was out of scope for this video (Angular CLi doesn't provide E2E integration). But it is a critical part for testing. In short, we do testing of logic with non-DOM tests, second layer are the DOM tests with Testing Library, Spectator or Cypress CT and then you have E2E which you usually can rely on a Webdriver-based framework or you go with Cypress/Playwright.
About jest, this appears, Your Jest configuration is outdated. Use the CLI to help migrating , on nodejs v20.10.0?
Hi, so my project is Angular 16 and I don't really see the need to update it. Angular 17 didn't actually change that much in terms of testing. We still have Karma and the Jest support is still experimental.
@@RainerHahnekamp I also don't see any advantages in switching to Jest, but the large corporations that pay my salary and use Jest, so I have to study Angular with Jest, 🥲🥲🥲🥲
For the 'testing-cli-jest-native' project, can you make a copy of the 'app.component.spec.ts' file into a sub-folder, fix the import, and then run the tests again? I get an error when there are .spec.ts files that have the exact same name but in different folders.
"Two output files share the same path but have different contents"
All the output files are being flattened into the 'dist\test-out' folder.
Hi, I wouldn't bother too much about this moment. This is an experimental version. It is not meant to be used in "real life". The Angular team wants to find out if their approach is the right one and feasible. You will see improvements in the "developer experience area" hopefully quite soon. I can't tell you how Jest support in Angular 17 will be, but maybe it will be much better than in 16.
Thank you@@RainerHahnekamp I did comment on a relevant issue on GitHub. The issue is being tracked. I agree that it's probably best wait until ng17 to try this again, since its experimental.
@@CaseyPlummer-y5ndo you have a link of that issue?
But Reinier, I only have about 60 tests so far, not 10 thousand like the Facebook developers have. Jest gives me nothing but a burden to upgrade because it is the new official path :-(
Hi Marc, if I would do this video now, I would not recommend Jest anymore. I expected that Jest will be available as developer preview in Angular 17 but the Angular team shifted its main focus towards the migration from Jasmine from Webtest Runner.
@@RainerHahnekamp please elaborate on this, should we consider switching from jasmine to jest?
@@VankataKisyov NO. We see that the official support for Web Test Runner and Jest didn't get so much attention from the Angular team and the situation in 2024 is the same. If you run right now on Jasmine, stay where you are, if you are on Jest and have no issues, also stay. If you have issues with Jest consider a switch to Jasmine.
In my video I said I would pick Jest because it looked like we official support already in Angular 17. As it stands no, it will probably be in 2025.
@@RainerHahnekamp I see, thank you!
so jest is not supported by angular, and karma is deprecated .... so what is currently supported by angular?
suppose i want to use testing framework supported by angular today what do i do if not jest or karma?
As I was saying at the end, given Jest's adoption in the JavaScript ecosystem, I would go with that one. You might be on a bumpy road with its community support at the moment, but once it is officially supported by Angular, I'm very optimistic that it will be a joy (also in terms of build performance).
If you want to play it safe, go with Karma/Jasmine. The transition from Karma to Web Test Runner will be done by migrations. Since Web Test Runner and Karma are just the runners, the code for your tests will not change. It is and will be Jasmine.
I would strongy discourage you from using any other framework than Jest or Jasmine. The integration into Angular is not a trivial task. Don't do it.
You could go with Vitest as an alternative. But then, you would have to use Analog on top of Angular. That's an option.
@@RainerHahnekamp thank you for your explanation and help, one last question ... Will the tests written in jasmine not run with jest? I'm under the impression that jest is built on top of jasmine so should the tests already written in jasmine still work correctly with jest? Thank you again
There is a jasmine runner in Jest but I’m not sure if that one is still available in the latest versions.
Jest emancipated itself from jasmine over the years. Especially in the area of mocking, spying, the commands are quite different.
In general, it is easy to migrate from jasmine to jest but you have to manually change some of your test code
What a mess! Thanks Rainer.
It is what it is. I guess when Angular takes over the support for Jest, the situation will be much better.
why jasmine karma still exists in v18?
Karma does still exist, because they are still working on the migration to Web Test Runner. To be fair, one has to say that Jasmine/Karma doesn't have any issues - it is running fine - so they don't see this task as main priority.
Jest will come after Web Test Runner is done and Jasmine will stay (as I said in the video).
Btw, in th meantime, I would use Jasmine for a new project. Given the troubles we have with Jest/Angular and the pace of the migrations, I am afraid official Jest support is something we get in 2025.
Last year, I had the impression that Jest will already be available in Angular 17.
I wonder how cypress fits in all of this
Yeah, so I decided not to cover Cypress or any other E2E testing tool in this video/article since it is about Jasmine and its alternatives. Maybe I do a reboot for 2024. Would probably include it there.
Nice explanation! Thanks for showing us the difference between Jasmine and Jest 🫡
You're welcome
Why not just use Selenium?
Selenium is for E2E testing. I am focussing here on the tooling for unit and component testing.