So basically the way you write the tests in typescript does not change? Is that correct? Because frankly I just started with this Jamine/Karma unit testing and was happy enough to get it running in the first place. :-(
I do not have to dump the tests I have made with such effort into the dustbin?
👋 Hello, I'm Rainer. I’m an application engineer with deep roots in Angular. Today, much of my work revolves around AI: Agentic UIs, AI-assisted software develpment, local models
Didn't have braces as a kid; now I deal with them everyday...
Fullstack Pragmatic Problem-Solver - not every technical solution needs you to write code.
Fantastic article! I'm spear-heading a unit testing implementation endeavour in my current role.
There was a lot of gravitation to try to dive straight into Jest - even though we wouldn't be able to use native Jest today. This article gave me valuable insight into some of the decision factors for consideration.
We're on a pre v16 version today and my evaluation is that considering this, and given that one of our primary objectives is to leverage automation in our build pipelines with coverage enforcement I'm recommending to the team that we stick with Jasmine and Karma on the existing projects and rather start exploring Jest on any green-fields apps where we would be starting with v17 (or latest).
Would be great to get your thoughts on whether this is a pragmatically future-proofed approach. Given your comment about the state of native Jest support in v17, I'm feeling like it is.
👋 Hello, I'm Rainer. I’m an application engineer with deep roots in Angular. Today, much of my work revolves around AI: Agentic UIs, AI-assisted software develpment, local models
👋 Hello, I'm Rainer. I’m an application engineer with deep roots in Angular. Today, much of my work revolves around AI: Agentic UIs, AI-assisted software develpment, local models
👋 Hello, I'm Rainer. I’m an application engineer with deep roots in Angular. Today, much of my work revolves around AI: Agentic UIs, AI-assisted software develpment, local models
👋 Hello, I'm Rainer. I’m an application engineer with deep roots in Angular. Today, much of my work revolves around AI: Agentic UIs, AI-assisted software develpment, local models
👋 Hello, I'm Rainer. I’m an application engineer with deep roots in Angular. Today, much of my work revolves around AI: Agentic UIs, AI-assisted software develpment, local models
👋 Hello, I'm Rainer. I’m an application engineer with deep roots in Angular. Today, much of my work revolves around AI: Agentic UIs, AI-assisted software develpment, local models
Great article!
Amazing!!!!
So basically the way you write the tests in typescript does not change? Is that correct? Because frankly I just started with this Jamine/Karma unit testing and was happy enough to get it running in the first place. :-(
I do not have to dump the tests I have made with such effort into the dustbin?
Yes, you can continue to write Jasmine tests and in some future version Angular will just switch the runner. For your codebase, nothing should change.
Fantastic article! I'm spear-heading a unit testing implementation endeavour in my current role.
There was a lot of gravitation to try to dive straight into Jest - even though we wouldn't be able to use native Jest today. This article gave me valuable insight into some of the decision factors for consideration.
We're on a pre v16 version today and my evaluation is that considering this, and given that one of our primary objectives is to leverage automation in our build pipelines with coverage enforcement I'm recommending to the team that we stick with Jasmine and Karma on the existing projects and rather start exploring Jest on any green-fields apps where we would be starting with v17 (or latest).
Would be great to get your thoughts on whether this is a pragmatically future-proofed approach. Given your comment about the state of native Jest support in v17, I'm feeling like it is.
Hi Rachel, thanks. Given Jest's current status, please stick to Jasmine whenever you can. That applies to green-field apps as well.
If Jest becomes necessary, it should be an officially supported version that uses Angular's build process.
Since the time of this article, Jest didn't really improve.
it's 2024 and we're still having the same problem. Jest is extremely slow even with the official builder
Yeah, time for an update. You're right except one thing. There is still no official builder...
I was confused with our setup initially. We use
@angular-buildersand it's not official oneQue buen articulo.. Me sirvio para tener un contexto actual del testing en Angular.
Gracias, estoy contento de saberlo.
While running
ng testcommand after setup.getting this error
dist/test-out/src in the roots[0] option was not found.Hi, in which one of the existing projects did that happen?
Great article. Any issues running code coverage? So far I'm getting 0%
Hi, I mean the goal was not really to measure code coverage. Is there something in particular, you want to know?
Hi, thanks for this great article!
Do you know if there's a way to launch tests in a watch mode using angular native jest?
No, not yet. I also have to say that the Jest support in Angular 17 didn't really improve compared to v16.