Great tutorial, thanks!

@RainerHahnekamp

Ай бұрын

You are welcome!

The way you explain it is so nice and easy to understand!

@RainerHahnekamp

4 ай бұрын

Thanks a lot. Happy to hear!

Hi Rainer. Brilliant video, thanks for taking the time! We usually cover DOM testing using Cypress E2Es. Do you think there is any advantage using DOM based tests in our unit tests too? We had been simply "newing" components before and supplying mocks in the constructor (without TestBed). Looks like we've have to move to TestBed in any case to use effects in the constructor.

@RainerHahnekamp

2 ай бұрын

Yeah, so independent that you don't have any other options to test effects, you need to ask yourself what benefits you get of non-DOM tests? I guess, you are directly calling methods of your TypeScript component then? If yes, here is an official statement from the Angular team on that topic: github.com/angular/angular/issues/54438#issuecomment-1971813177 Tests without DOM access are usually done against Services or heavy-logic based functions.

@awesomewidgets4298

2 ай бұрын

@@RainerHahnekamp Thanks Rainer! Yeah, we normally call the functions directly and test that the logic is correct. We do extract a lot of the logic into standalone (pure) util functions a lot of the time and test them separately. My thoughts were that DOM tests will test the angular wiring which is already tested by Cypress, but from your video I can see the benefit that you can refactor and the tests will still run (and still be meaningful) as they are abstracted a little from the nitty-gritty of the implementation. They are also a lot faster than e2e tests.

Great explanations

@RainerHahnekamp

4 ай бұрын

Thank you Paul. Signals look easy at first sight, it is a little bit more complicated with glitch-free but once you understand that one, it is straight-forward

Excellent video

@RainerHahnekamp

4 ай бұрын

Thanks a lot John.

Awesome video that really clarifies the basics! Quick question: When starting out with the expectations for the effect, you said that the effect will not run until After ChangeDetection. I am a bit confused here, since the docs say that effects run at least once initially. Why was the effect not run initially in this case?

@RainerHahnekamp

4 ай бұрын

Yes, because the docs assume that Change Detection is always part of the game. "run initially" means that the effect starts to be dirty. So you always have at least once execution in the change detection. Does this answer your question?

Very nice Video Rainer

@RainerHahnekamp

4 ай бұрын

Thank you DJ

very good video, so same method applies to my signalStore, or do i have to do something different ?

@RainerHahnekamp

Ай бұрын

Yes, the SignalStore is an Angular Service which exposes native Signals. All things apply there as well.

It seems to me that flushEffects won't catch bugs when the effect is called more than it is expected. My theory is if you call the flushEffects 2 times it will only execute the effect at max 2 times. So if the effect would have run 2 times between the flushEffects calls, instead it will only exeute once, therefore resulting in invalid test result(s). In order to workaround this you can call flushEffects after every interaction with the service but that's horribly DX in my oppinion. What would you suggest in this case @RainerHahnekamp ?

@RainerHahnekamp

4 ай бұрын

Hi Norbert, yes, you are right. When Angular's change detection would run an effect two times and you miss to call flushEffects at the right time in the test, the effect runs only once. So you end up with a test which gives you wrong results. That's why the recommendation is to avoid flushEffecs at all and test as much as you can via the DOM. You can still miss there to run detectChanges but chances aren't that high because you require detectChanges also for your other assertions against the DOM.

Thanks Rainer for the videos. A bit off topic, but I wanted to ask about new builders in Angular based on esbuild. It seems that esbuild does not support dynamic import, so it gave me an error when changed the route to lazy loaded module. So we can,t use esbuild with lazy loaded routes?

@RainerHahnekamp

4 ай бұрын

Hi Giorgi, I am not aware of any issues like that. I've done all my latest videos with Angular 17, esbuild and lazy loaded modules. It works. Please compare your angular.json config with mine. Maybe there is something you've missed.

@giorgipaikidze85

4 ай бұрын

@@RainerHahnekamp ok, will check, thanks. I updated recently with nx. In Angular documentation they say that you just need to change browser with browser-esbuild and nothing else. Seems there is something needed. At least now I know it. Thanks.

@RainerHahnekamp

4 ай бұрын

@@giorgipaikidze85 I see, you might want to check if it is not something nx-related. Don't know, maybe you use publishable libraries which are running on webpack... don't know what Nx would do in that case.

What is color scheme/font family?

@RainerHahnekamp

4 ай бұрын

Hi, I am always using the font ASAP.