Just want to say that this is one of the best videos I've seen about automated testing. It addresses exactly what people experience trying to test w/ karma and shows all the different methods with their pros and cons. The example is relatively simple, but manages to hit all the right notes to address many of the common pains people are dealing with.
Thanks Yaroslav, at the time of this recording, I think that option wasn't available. I had plans to come up with another video but as things are the moment, I think it will be Playwright Component Testing.
tyvm! thanks to this video, I could finally solve the issue with empty cdk-overlay-container while running component tests. importing BrowserAnimationsModule helped.
thanks a lot for this relevant info! I started working on research to handle the testing of a new react application so the components are going to be delivered in the next weeks and I was thinking on the e2e testing more than the component testing. I like your approach and it is a good time to implement this new cypress feature. Greetings from Peru!
Great, so component testing for React is - as far as I know - more sophisticated than in Angular. We have official Angular support since a month whereas in React it is more than a year. Greetings from Austria!
Great video with great explanation and great examples. Thank you. Will try cypress on my pet project. And looks like it might be good one to have something like regression test on application (in case if it's not big)
@@RainerHahnekamp in our cypress.config.ts file we need to write some configuration parameters for component testing. I had problem with it as I was trying to do component testing I have spent about an hour and could not run any component test, I had constantly some issues. So it will be great if you show how you configured everything for component testing. thanks.
Great video 👍 Regarding the icons, couldn’t you change the cypress component html file to always include the icons? That way you would not need the wrapper.
Hi Leon, you are absolutely right. The wrapper approach would be better in cases where I need to emulate a parent component. For global elements like fonts, changing the component.html directly is the way to go.
Thank you for this great introduction to Cypress! I would love to see a future video on Cypress Component Test with Standalone component. With Standalone Component, Cypress component tests would be Deep tests by default because all children and children's children ... are transparent. Will Cypress have API for mocking child components (like ng-mocks) and is it even recommended to mock child components, in your opinion? I would also appreciate if you could point to any resource on the equivalence of fakeAsync/tick for mocking time passage in Cypress. fakeAsync/tick relies on zone.js/testing and I am concerned that Cypress does not handle this properly yet
Hi, yeah, so please use ng-mocks in Cypress for mocking components. It works out of the box. For fakeAsync/tick it is a different story. In general, Cypressh handles asynchrony quite. You usually don't really have to care about it. There is also a cy.clock which works similar to tick. Unfortunately, it has no effect in component tests. So at the moment I cannot give you a full answer about fakeAsync.
Awesome Vid and definitely Cypress Component Testing just seems very natural. I do have a question on how to setup Mock data for NgRx. Anyone did this yet? Would love a sample code or even video would be better!
Thanks, I am thinking about creating a second episode with some common use cases. That would include an ngrx store, mocking services and also things like modal dialog as Victor Paranin asked already. As soon as I have 5 examples, I would start recording it.
For NgRx specifically, you can import the StoreModule and the Effects, register the feature state and mock the HttpRequest from the effects. In that case, your test would also cover ngrx
Hello Marcos, thanks for the compliment. To be honest, with Cypress Component Testing, I am not sure if Spectator is still the tool to pick if you start a new project. How do you see it?
Great video resume of all ways to test component in Angular. One question Rainer, could you do a video about the usage or not of TestBed for Unit tests with some examples? I read and listened about it but different opinions and not much examples found. Thanks in advanced
Hi, happy you liked my video. I am aware of the different opinions towards testing with the TestBed. Although I have a written draft about this very topic, I have a list of videos I want to do before. If you wish, you can lay out your arguments that speak against using the TestBed here and I can give you my opinion.
Hello, so it looks that video I've promised is not necessary anymore. Since Angular has introduced the inject function, there is not really a way around the TestBed. If you are interested in more details, this is the video that covers it: ua-cam.com/video/Tvsa4OMUGXs/v-deo.html
Noticed in your examples that the notorious red squiggly line appears in the "expect" statements. Possibly a problem when including the cypress library? I would treat these as warnings to heed by and wonder why you don't seem to care abiut them.
Oh, you have no idea how much I care about them when the camera is not on :). My IDE confused mocha and jest (both were running in this project). So it was not something related to Cypress or TypeScript itself, because during compilation the right expect was used. I once managed to fix it for the IDE as well by excluding the cy.ts from one of the many tsconfig.json. Do you need a fix?
great video Reiner thanks! my question is can I use cypress for unit testing too? and not use 2 frameworks for unit and component testing? I searched for it but apparently the configuration for cypress is quite complex
Hello Babak, according to my information Cypress has plans to come up with unit testing support for Angular. So if you don't have pressure at the moment, you might want to wait until they offer it.
In the version that I used, there were some issues with the DI, you had to fallback to the mocking tools of Cypress itself: docs.cypress.io/guides/guides/stubs-spies-and-clocks#Stubs I haven't checked the last version yet. Maybe it is already fixed.
Hey, very useful video :) but I have some considerations... In our company, we have monorepo with 3 Angular applications. Applications are split into small libs (data-access, feature, ui). For now, we have some unit tests (for "dumb" ui components, and services) but we want to test more. We want to test "features" - smart components, dumb components, NGRX store, services - as a whole (only http requests to backend should be mocked). I tried "Cypress Component Testing", but it's really hard to prepare "cy.mount" that everything works properly - ngrx store, translations (@ngx-translate), styles (angular material + tailwind), keycloak (angular-auth-oidc-client). Do you have any advice on that? Maybe we should use for those type of tests "cypress e2e", but mock http requests to backend? What do you think?
Hi, so you are right; the setup process in Cypress is the same as if you would go with classic tools like Jasmine or Jest. Cypress only helps you when it comes to the actual execution part of the test. Some tips I found useful: 1. When you want to cover as much as possible in your tests, Standalone Components could help you a lot. They already have the dependencies for your components/directives/pipes. What's missing is providing the services. You named it already: ngrx, translate, oauth2, etc.. 2. some services are used more or less in every test. So it would make sense to set up own provide functions for oauth2, translate, etc. In terms of OAuth2, I would recommend to completely mock that one away. Those tips might sound like a lot of work, but you do that once, and then you have tests with quite a heavy coverage. Do you understand what I mean by "setting up own provider functions" in 2. or do you need more information on that?
@@RainerHahnekamp Thank you very much for your response! "setting up own provider functions" - by that do You mean functions like "provideRouter" etc.? I have one more question: Do you think in case of tests which I described before (tests that checks UI but mock all backend/OAuth requests) I should use "cypress component tests" instead of "cypress e2e"?
Yes, exactly. But instead of provideRouter, you might have a `provideMockedTranslation` which provides all the services that mock ngx-translate. I you don't want to mock it, you can of course use the original services. And in the same way, you create your provide functions for oauth2, ngrx, etc. When you want test features as a whole, I think E2E gives you results much faster. On the other side, you might be limited because E2E-testing is slower than component tests. Meaning you will not be able to have that amount of e2e tests that you have with component tests. Generally speaking. I would say cover the main parts via E2E and then for the uncovered ones (or where E2E doesn't work) go with component tests.
what do u prefer in a enterprise application, all testing ? unit , component and e2e testing , or you will skip some kind of testing, and what will u prefer for small projects ? and what advice u give for someone who is starting TDD
You will require all three types. The amount of unit tests depends on the amount of business logic you have in your frontend application. If you just fetch data from the server and send it directly back, there is not so much logic and you will rely more on component and e2e tests. The constraint in E2E testing is most of the times the speed. They are very slow. So you can have only a limited amount of them. So make sure you cover your critical use cases with them. Integration / Component Tests will then probably be the majority, whereas the amount of Mocking in Component tests is high and in integration tests low. If your application allows it, try to prioritize integration tests and use component tests mainly for components that are shared and used in multiple use cases. In terms of TDD start with a component or integration test. If you see that your amount of logic increases, you can always add unit tests for the edge cases. That being said, this my recommendation in general. Every application is individual but in most cases the described approach can be applied.
Hi Felipe, in short, Cypress is working on it. They have already an experimental feature for it, but I am not sure if it is limited to e2e only. This is the type of bug that looks very easy to fix from the outside, but inside it is a total nightmare. You can read more about it here: github.com/cypress-io/cypress/discussions/21628
@@RainerHahnekamp yep, it's true. It would be great if you share how you test modal components via cypress component testing. For example, it is not a problem to render the dialog material as a normal component, but in this case, part of the functionality for testing is lost, for example, closing a modal window with passing certain parameters, or adding a certain class to the panel, depending on the logic
@@victorparanin8081 Just to be sure, you want to see a Cypress component test, where a component is calling a modal dialog, which can, for example, contain a form. the user provides some data, and the hosting component processes it. Something like that?
Hi Rahul, so with unit tests you mean the ones where the TestBed is not used, right? Since they are more or less covering only typescript classes, studying the Jest or Jasmine documentation is a good start. Further more, you also have to deal with asynchrony where Angular's documentation about fakeAsync and waitForAsync is recommended.
@@darkvader37 Yeah, I guess it is time that I do something about it. It all comes down to this file here: github.com/cypress-io/cypress/blob/develop/npm/webpack-dev-server/src/helpers/angularHandler.ts. Need to find out if it has an option to add an own webpack.config or if this is a feature that should be added. If that's possible, it would be the same as it is with code coverage in Cypress E2E
Hi, would you know if I have a component A which extends a directive B. And in comp. a I am in injecting a service A with inject and inside of the constructor I am also calling super and injecting the service A. The question is, am I creating 2 instances os service A? Thanks in advance.
@@RainerHahnekamp see if that peace helps. private processStepPackService: ProcessStepPackService = inject(ProcessStepPackService); constructor(){ super ("ProcessStepPack", inject (ProcessStepPackService)); } In that case where I am injecting ProcessStepPackService twice. Would that be 2 instances or still just one?
Just want to say that this is one of the best videos I've seen about automated testing. It addresses exactly what people experience trying to test w/ karma and shows all the different methods with their pros and cons. The example is relatively simple, but manages to hit all the right notes to address many of the common pains people are dealing with.
Hey, happy to hear, and yeah, I went through all these stages in testing ;)
Great video, thank you for the professional step by step guide.
You are welcome. My pleasure
It was a great pleasure to see your video. This is a great news to see an another way to write test components 👍👍👍
Hello Bou, thank you very much. Look out for Cypress v11. It will receive further features for Angular testing.
Great video, thanks for uploading. The level of expertise you have is very high.
I have subscribed.
Hey, thanks and welcome to my channel :)
Another amazing video! Thank you again, sir, for all the great Angular content!
Much obliged, sir!
Great video! Thanks!
I'd add that it's possible to specify an index.html file for all component tests in Cypress in order to load styles and fonts.
Thanks Yaroslav, at the time of this recording, I think that option wasn't available. I had plans to come up with another video but as things are the moment, I think it will be Playwright Component Testing.
@@RainerHahnekamp I wish Playwright supported component testing for Angular 🙂
@@_YaroslavIt is just a question of weeks. They have been working on it for quite some time and the good thing is, it was community-driven.
tyvm! thanks to this video, I could finally solve the issue with empty cdk-overlay-container while running component tests. importing BrowserAnimationsModule helped.
Great! NoopAnimationsModule wasn't working?
@RainerHahnekamp yep, for some reason, it threw this.driver.validate style property is not a function but my @angular/animations is 16.2.12
thanks a lot for this relevant info! I started working on research to handle the testing of a new react application so the components are going to be delivered in the next weeks and I was thinking on the e2e testing more than the component testing. I like your approach and it is a good time to implement this new cypress feature. Greetings from Peru!
Great, so component testing for React is - as far as I know - more sophisticated than in Angular. We have official Angular support since a month whereas in React it is more than a year.
Greetings from Austria!
Great video with great explanation and great examples. Thank you. Will try cypress on my pet project. And looks like it might be good one to have something like regression test on application (in case if it's not big)
Thank's a lot. And yeah, you should definitely give it a try as component testing left the beta status in Cypress 11.
Absolute gem. Great video
Thanks Shashank, great to hear that you liked it.
very clear and helpful explanation. Thank you man🤙
Thanks as well. Please be aware that in the meantime the Cypress API changed a little bit. Not that much, but a little bit.
some info about special configs for component testing would be great.
What exactly are you looking for?
@@RainerHahnekamp in our cypress.config.ts file we need to write some configuration parameters for component testing. I had problem with it as I was trying to do component testing I have spent about an hour and could not run any component test, I had constantly some issues. So it will be great if you show how you configured everything for component testing. thanks.
Great video 👍
Regarding the icons, couldn’t you change the cypress component html file to always include the icons?
That way you would not need the wrapper.
Hi Leon, you are absolutely right. The wrapper approach would be better in cases where I need to emulate a parent component. For global elements like fonts, changing the component.html directly is the way to go.
Thank you for this great introduction to Cypress! I would love to see a future video on Cypress Component Test with Standalone component.
With Standalone Component, Cypress component tests would be Deep tests by default because all children and children's children ... are transparent. Will Cypress have API for mocking child components (like ng-mocks) and is it even recommended to mock child components, in your opinion?
I would also appreciate if you could point to any resource on the equivalence of fakeAsync/tick for mocking time passage in Cypress. fakeAsync/tick relies on zone.js/testing and I am concerned that Cypress does not handle this properly yet
Hi, yeah, so please use ng-mocks in Cypress for mocking components. It works out of the box. For fakeAsync/tick it is a different story. In general, Cypressh handles asynchrony quite. You usually don't really have to care about it. There is also a cy.clock which works similar to tick. Unfortunately, it has no effect in component tests. So at the moment I cannot give you a full answer about fakeAsync.
@@RainerHahnekamp Thanks for getting back, and please keep making these great videos!
Nice tutorial, thanks Rainer🍻🍻
You are welcome. Happy you liked it.
Thanks for the video. Learned a lot!
You are welcome. Hope to come up with the second part as well :).
Thanks a lot for this awesome video, It is really helpful!
Happy to hear!
Awesome Vid and definitely Cypress Component Testing just seems very natural. I do have a question on how to setup Mock data for NgRx. Anyone did this yet? Would love a sample code or even video would be better!
Thanks, I am thinking about creating a second episode with some common use cases. That would include an ngrx store, mocking services and also things like modal dialog as Victor Paranin asked already. As soon as I have 5 examples, I would start recording it.
For NgRx specifically, you can import the StoreModule and the Effects, register the feature state and mock the HttpRequest from the effects. In that case, your test would also cover ngrx
Amazing content, could you make a crash course about Spectator?
Hello Marcos, thanks for the compliment. To be honest, with Cypress Component Testing, I am not sure if Spectator is still the tool to pick if you start a new project. How do you see it?
Great video resume of all ways to test component in Angular. One question Rainer, could you do a video about the usage or not of TestBed for Unit tests with some examples? I read and listened about it but different opinions and not much examples found. Thanks in advanced
Hi, happy you liked my video.
I am aware of the different opinions towards testing with the TestBed. Although I have a written draft about this very topic, I have a list of videos I want to do before.
If you wish, you can lay out your arguments that speak against using the TestBed here and I can give you my opinion.
Hello, so it looks that video I've promised is not necessary anymore. Since Angular has introduced the inject function, there is not really a way around the TestBed. If you are interested in more details, this is the video that covers it: ua-cam.com/video/Tvsa4OMUGXs/v-deo.html
Great content, thanks!
Thanks Vinayak!
Noticed in your examples that the notorious red squiggly line appears in the "expect" statements. Possibly a problem when including the cypress library? I would treat these as warnings to heed by and wonder why you don't seem to care abiut them.
Oh, you have no idea how much I care about them when the camera is not on :). My IDE confused mocha and jest (both were running in this project). So it was not something related to Cypress or TypeScript itself, because during compilation the right expect was used. I once managed to fix it for the IDE as well by excluding the cy.ts from one of the many tsconfig.json. Do you need a fix?
Indeed, I am struggling with the same bothersome issue between cypress and jasmine/mocha. A proper fix would be greatly appreciated.
great video Reiner thanks! my question is can I use cypress for unit testing too? and not use 2 frameworks for unit and component testing? I searched for it but apparently the configuration for cypress is quite complex
Hello Babak, according to my information Cypress has plans to come up with unit testing support for Angular. So if you don't have pressure at the moment, you might want to wait until they offer it.
Also, how I can mock services that's being used in the Component. Thanks again!
In the version that I used, there were some issues with the DI, you had to fallback to the mocking tools of Cypress itself: docs.cypress.io/guides/guides/stubs-spies-and-clocks#Stubs I haven't checked the last version yet. Maybe it is already fixed.
Hey, very useful video :) but I have some considerations...
In our company, we have monorepo with 3 Angular applications. Applications are split into small libs (data-access, feature, ui). For now, we have some unit tests (for "dumb" ui components, and services) but we want to test more. We want to test "features" - smart components, dumb components, NGRX store, services - as a whole (only http requests to backend should be mocked).
I tried "Cypress Component Testing", but it's really hard to prepare "cy.mount" that everything works properly - ngrx store, translations (@ngx-translate), styles (angular material + tailwind), keycloak (angular-auth-oidc-client).
Do you have any advice on that? Maybe we should use for those type of tests "cypress e2e", but mock http requests to backend? What do you think?
Hi, so you are right; the setup process in Cypress is the same as if you would go with classic tools like Jasmine or Jest. Cypress only helps you when it comes to the actual execution part of the test.
Some tips I found useful:
1. When you want to cover as much as possible in your tests, Standalone Components could help you a lot. They already have the dependencies for your components/directives/pipes. What's missing is providing the services. You named it already: ngrx, translate, oauth2, etc..
2. some services are used more or less in every test. So it would make sense to set up own provide functions for oauth2, translate, etc. In terms of OAuth2, I would recommend to completely mock that one away.
Those tips might sound like a lot of work, but you do that once, and then you have tests with quite a heavy coverage.
Do you understand what I mean by "setting up own provider functions" in 2. or do you need more information on that?
@@RainerHahnekamp Thank you very much for your response!
"setting up own provider functions" - by that do You mean functions like "provideRouter" etc.?
I have one more question: Do you think in case of tests which I described before (tests that checks UI but mock all backend/OAuth requests) I should use "cypress component tests" instead of "cypress e2e"?
Yes, exactly. But instead of provideRouter, you might have a `provideMockedTranslation` which provides all the services that mock ngx-translate. I you don't want to mock it, you can of course use the original services. And in the same way, you create your provide functions for oauth2, ngrx, etc.
When you want test features as a whole, I think E2E gives you results much faster. On the other side, you might be limited because E2E-testing is slower than component tests. Meaning you will not be able to have that amount of e2e tests that you have with component tests.
Generally speaking. I would say cover the main parts via E2E and then for the uncovered ones (or where E2E doesn't work) go with component tests.
what do u prefer in a enterprise application, all testing ? unit , component and e2e testing ,
or you will skip some kind of testing,
and what will u prefer for small projects ?
and what advice u give for someone who is starting TDD
You will require all three types. The amount of unit tests depends on the amount of business logic you have in your frontend application. If you just fetch data from the server and send it directly back, there is not so much logic and you will rely more on component and e2e tests.
The constraint in E2E testing is most of the times the speed. They are very slow. So you can have only a limited amount of them. So make sure you cover your critical use cases with them.
Integration / Component Tests will then probably be the majority, whereas the amount of Mocking in Component tests is high and in integration tests low. If your application allows it, try to prioritize integration tests and use component tests mainly for components that are shared and used in multiple use cases.
In terms of TDD start with a component or integration test. If you see that your amount of logic increases, you can always add unit tests for the edge cases.
That being said, this my recommendation in general. Every application is individual but in most cases the described approach can be applied.
And regarding small projects: A bunch of E2E should do it. The larger though, you have to bring in the other types as well.
@@RainerHahnekamp thank you so much 🙏 you are awesome
@@brucearmstrong5536 Thanks Bruce!
How can we run all cypress component tests at once? very annoying to have to run one by one..
Hi Felipe, in short, Cypress is working on it. They have already an experimental feature for it, but I am not sure if it is limited to e2e only.
This is the type of bug that looks very easy to fix from the outside, but inside it is a total nightmare. You can read more about it here: github.com/cypress-io/cypress/discussions/21628
Great!
Thanks!
Great job! May I ask you, how can we call the material modal component with data?
Hello Victor, thanks. Which component do you mean? The RequestInfo component in my example is not a modal.
@@RainerHahnekamp yep, it's true. It would be great if you share how you test modal components via cypress component testing. For example, it is not a problem to render the dialog material as a normal component, but in this case, part of the functionality for testing is lost, for example, closing a modal window with passing certain parameters, or adding a certain class to the panel, depending on the logic
@@victorparanin8081 Just to be sure, you want to see a Cypress component test, where a component is calling a modal dialog, which can, for example, contain a form. the user provides some data, and the hosting component processes it. Something like that?
@@RainerHahnekamp Right. I didn't find examples on the Internet and I think it will be useful to many people
Can I do Cypress component testing for the application which is anuglar 12 or 13
Hello, so the minimum version for Angular is 13. You might try your luck with version 12 but the official requirement is 13.
I am beginner and have worked on a couple of projects in angular. Could you suggest where to look to learn unit testing in angular?
Hi Rahul, so with unit tests you mean the ones where the TestBed is not used, right? Since they are more or less covering only typescript classes, studying the Jest or Jasmine documentation is a good start. Further more, you also have to deal with asynchrony where Angular's documentation about fakeAsync and waitForAsync is recommended.
How do you get code coverage for Cypress component tests? It's strange I can't find any documentation for that.
That's a good point. I think that this feature is missing for Angular. Give me some time. I'll try to come up with a solution.
@@RainerHahnekamp Thanks for catching it was for Angular, and I look forward to your reply.
@@RainerHahnekamp was looking this up today, but unfortunately wasn't able to figure out a solution
@@darkvader37 Yeah, I guess it is time that I do something about it. It all comes down to this file here: github.com/cypress-io/cypress/blob/develop/npm/webpack-dev-server/src/helpers/angularHandler.ts. Need to find out if it has an option to add an own webpack.config or if this is a feature that should be added. If that's possible, it would be the same as it is with code coverage in Cypress E2E
Hi, would you know if I have a component A which extends a directive B.
And in comp. a I am in injecting a service A with inject and inside of the constructor I am also calling super and injecting the service A. The question is, am I creating 2 instances os service A? Thanks in advance.
Dear Yuri, could you maybe provide me a small code snippet? Thank you
@@RainerHahnekamp see if that peace helps.
private processStepPackService: ProcessStepPackService = inject(ProcessStepPackService);
constructor(){
super ("ProcessStepPack", inject (ProcessStepPackService));
}
In that case where I am injecting ProcessStepPackService twice. Would that be 2 instances or still just one?
@@leiayuri Ah, that should be just one. You would get multiple instances with different provides but not by calling inject multiple times
@@RainerHahnekamp thank you so much. It was very helpful.
perfecting testing, testing is fun now. I got it dude :D
Great, happy to see that I got the message across :)