How do I test Signals (signal / computed / effect)

Signals as lightweight "reactive primitive" will shape the future of Angular applications.
At the time of this recording, signal() and computed() are stable, and effect() is in "developer preview".
We see increasing integration of Signals into the Angular API, and there should be no more reason to hold us back from using Signals.
What are the requirements?
First, we must understand Signals' behavior, which means the glitch-free effect (aka push/pull). Second, we need to be able to test them.
And that's exactly what this video covers.
The GitHub repository is available at: github.com/rainerhahnekamp/ho...
A written version is available at: dev.to/this-is-angular/how-do...
0:00 Introduction
0:05 Application Demo
2:10 Testing with Change Detection
11:10 Testing without Change Detection
19:47 Farewell

[@ViniciusLopesDeAlmeida]

Another Great Vídeo!!

[@RainerHahnekamp]

Thanks

[@svenson95]

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

[@RainerHahnekamp]

Thanks a lot. Happy to hear!

[@murhafsousli7191]

Great tutorial, thanks!

[@RainerHahnekamp]

You are welcome!

[@johncerpa3782]

Excellent video

[@RainerHahnekamp]

Thanks a lot John.

[@paulh6933]

Great explanations

[@RainerHahnekamp]

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

[@awesomewidgets4298]

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]

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]

@@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.

[@DebugModeVideos]

Very nice Video Rainer

[@RainerHahnekamp]

Thank you DJ

[@norbertszacsuri4560]

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]

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.

[@DyesViolet]

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]

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?

[@DerAlexD]

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.

[@giorgipaikidze85]

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]

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]

@@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]

@@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.

[@user-om2ve1fg1o]

What is color scheme/font family?

[@RainerHahnekamp]

Hi, I am always using the font ASAP.