Cypress Component Testing in Angular 

Hey, happy to hear, and yeah, I went through all these stages in testing ;)

You are welcome. My pleasure

Hello Bou, thank you very much. Look out for Cypress v11. It will receive further features for Angular testing.

Hey, thanks and welcome to my channel :)

Much obliged, sir!

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!

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.

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 Shashank, great to hear that you liked it.

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!

You are welcome. Happy you liked it.

You are welcome. Hope to come up with the second part as well :).

Thanks as well. Please be aware that in the meantime the Cypress API changed a little bit. Not that much, but a little bit.

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.

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.

Thank's a lot. And yeah, you should definitely give it a try as component testing left the beta status in Cypress 11.

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.

Happy to hear!

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.

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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Tvsa4OMUGXs.html

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.

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

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.

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

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.

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?

Hello, so the minimum version for Angular is 13. You might try your luck with version 12 but the official requirement is 13.

Thanks Vinayak!

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

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.

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!

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

Thanks!

Great, happy to see that I got the message across :)