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

Rainer Hahnekamp
4 Mar 202420:14

Summary

TLDRThis video introduces Angular's new feature, Signals, which was released as a developer preview in version 16 and has since been enhanced with exclusive features such as local change detection and signal inputs by version 17.1. The video delves into the practical integration and testing of signals within Angular applications, focusing on a case study of a basket component to demonstrate how signals, computed functions, and effects can be utilized to manage state changes and synchronize services. The presenter, an Angular Architects trainer and consultant, shares insights on testing components and services, emphasizing the importance of understanding signal dependencies and the role of change detection in triggering effects. This guide is invaluable for developers looking to leverage Angular Signals in their projects.

Takeaways

  • 🚀 Angular introduced Signals as a developer preview in version 16, with version 17.1 adding exclusive features like local change detection and signal inputs.
  • 🔒 By version 17, the signal function and computed function became stable, while the effect function remained in developer preview, offering new advantages for application integration.
  • 🧪 Testing components using signals in Angular requires understanding of lifecycle hooks, change detection, and the effects of computed and effect functions on the component's state.
  • 🔧 The Basket Component example demonstrates handling of products with signals for dynamic price calculation, employing services for synchronization and utilizing computed for total price calculation.
  • 👩‍💻 Component testing involves interacting with the DOM through TestBed to instantiate the component, trigger events, and verify outcomes without directly accessing component instance variables.
  • ⚙️ Effects triggered by signals depend on change detection to execute, necessitating understanding of how Angular processes changes and updates the DOM based on signal state.
  • 📌 Testing effects within components differs from service testing due to the absence of DOM interactions and change detection, requiring manual triggering of effects through test utilities.
  • 🔄 Refactoring components by extracting logic into services can streamline testing and improve code organization, while still allowing for comprehensive component behavior verification.
  • 🧼 For service testing without change detection, the `flushEffects` utility is essential for manually triggering effects that are dependent on signal changes, ensuring accurate test results.
  • 📚 The script underscores the importance of understanding Angular's signal-based architecture for effective testing, highlighting strategies for both component and service-level tests.

Q & A

  • What version of Angular introduced signals as a developer preview?

    -Signals were introduced in Angular version 16 as a developer preview.

  • By Angular version 17.1, which features of signals became stable?

    -By Angular version 17.1, the signal function and the computed function became stable.

  • Which function related to Angular signals is still in developer preview as of version 17.1?

    -As of version 17.1, the effect function related to Angular signals is still in developer preview.

  • What is the purpose of the effect function in the context of Angular signals?

    -The effect function is used to execute some kind of synchronization or side effects whenever the dependent signals change.

  • How does the 'total price' feature work in the basket component example?

    -The total price in the basket component example recalculates the total cost whenever the quantity of products is increased or decreased.

  • What is the significance of using 'fixture.detectChanges()' in Angular component testing?

    -'fixture.detectChanges()' is used to initiate the Angular lifecycle hooks and update the component with the latest data, ensuring the tests reflect the current state of the component.

  • How is the 'flushEffects' method useful in testing Angular services with effects?

    -The 'flushEffects' method triggers the execution of any dirty (changed) effects manually, which is necessary in service tests where there is no automatic change detection.

  • Why is it important to understand when an effect is considered 'dirty' in Angular?

    -Knowing when an effect is 'dirty' is crucial because a 'dirty' effect signifies that its dependencies have changed, necessitating a re-execution of the effect to reflect the new state.

  • What refactoring was done to the basket component in the example?

    -The logic was refactored out of the basket component and moved into a separate basket service to simplify the component and isolate the logic for testing.

  • Why is it necessary to test both the Angular component and service separately in the context of signals?

    -Testing both the component and service separately ensures that the logic within the service functions correctly independent of the component and that the component interacts with the service as expected.

Outlines

00:00

🔍 Introduction to Angular Signals and Testing Components

Angular has introduced signals in version 16 as a developer preview, and by version 17.1, features like local change detection and signal inputs have become exclusive with signals. The signal and computed functions have become stable, while the effect function remains in developer preview. The video discusses the advantages of integrating signals into applications, the need for careful testing, and presents a case study on testing a basket component that uses signals to manage products and their total price. It covers the basics of setting up a component test, initializing the component, and testing dynamic changes in the DOM based on user interactions.

05:02

🚀 Advanced Testing Techniques with Angular Signals

The second part delves into more advanced testing scenarios, including verifying the recalculated total price upon product updates, and the execution of the sync service effect upon product changes. The narrative emphasizes the importance of triggering change detection to update the DOM and ensure that computed properties and effects reflect the current state. It also introduces the concept of effects being 'dirty' and the necessity for external triggers (like change detection) to execute effects, highlighting the intricacies of testing Angular components and services that utilize signals.

10:05

🛠️ Solving Effects Testing Challenges in Angular Services

This section explores the idea of refactoring the basket component to move logic into a separate service for cleaner architecture and easier testing. It walks through the process of injecting the basket service into the component, adjusting the template, and providing service methods for UI interactions. The emphasis shifts to testing the basket service directly, illustrating how to access services via Angular's testbed and highlighting differences in testing strategies between components and services, especially regarding computed values and effects without direct change detection.

15:06

📢 Conclusion and Invitation to Angular Testing Workshop

The video concludes with a summary of the key points discussed, emphasizing the importance of understanding and integrating Angular signals into application development and testing. The presenter, identified as R Hamp from Angular Architects, invites viewers to learn more about Angular testing through their workshop. The closing remarks encourage viewer engagement through likes, subscriptions, and comments, promising more informative content in future videos.

Mindmap

Keywords

💡Signals

Signals are a new feature introduced in Angular as a developer preview in version 16. They are a reactive programming model that allows developers to manage application state and respond to changes in a more efficient and declarative way. In the video, signals are discussed as a replacement for traditional change detection mechanisms, offering features like local change detection and signal inputs.

💡Change Detection

Change detection is a mechanism in Angular that determines when changes have occurred in the application and updates the view accordingly. In the context of the video, it is discussed as a crucial component for triggering effects and computed functions associated with signals. The video highlights the importance of understanding how change detection interacts with signals, especially when testing components with signals.

💡Effects

Effects are a part of the signals ecosystem in Angular. They are functions that can perform side effects, such as logging, making HTTP requests, or updating a service, in response to changes in signals. In the video, the effect function is mentioned as a developer preview feature, and it is demonstrated how effects are triggered by change detection or the flush effects command during testing.

💡Computed

Computed functions are part of the signals ecosystem in Angular. They are functions that derive their values from one or more signals, allowing for reactive derivations based on signal state changes. In the video, the computed function is used to calculate the total price based on the products signal, and it is shown how computed values can be tested.

💡Component Testing

Component testing is a practice in Angular development that involves testing individual components to ensure their functionality and behavior are as expected. In the video, component testing is demonstrated using Angular's testing utilities, such as TestBed, configureTestingModule, and createComponent. The video showcases how to test components that use signals, including accessing the component's DOM and verifying computed values.

💡Service Testing

Service testing is the practice of testing Angular services in isolation, separate from components or other parts of the application. In the video, service testing is discussed in the context of testing the BasketService, which contains the logic for managing products and their prices. The video highlights the importance of using the flush effects command to trigger effects when testing services that use signals.

💡TestBed

TestBed is a utility provided by Angular for configuring and creating an environment for running tests. In the video, TestBed is used to configure the testing module, inject services, and create component fixtures. It is an essential tool for setting up and executing tests in Angular applications.

💡Spies

Spies are a testing technique used to track and verify the behavior of functions or methods. In the video, spies are used to monitor the execution of the sync service's sync method when testing the effects associated with signals. Spies allow developers to assert whether a function was called, how many times it was called, and with what arguments.

💡Flush Effects

Flush effects is a command provided by Angular's testing utilities that triggers the execution of effects associated with signals. In the video, it is demonstrated that when testing services without change detection, the flush effects command must be used to trigger effects manually. This is necessary because effects rely on change detection or flush effects to execute when they are marked as dirty.

💡Refactoring

Refactoring is the process of restructuring existing code without changing its external behavior. In the video, refactoring is discussed in the context of moving logic from the BasketComponent to the BasketService. The presence of tests allows the developer to verify that the refactoring did not introduce any bugs or unintended changes in the application's behavior.

Highlights

Signals introduced in Angular version 16 as a developer preview, with version 17.1 already featuring exclusive signal-related enhancements.

Stabilization of the signal and computed functions in Angular 17, with the effect function remaining in developer preview.

Discussion on integrating signals into applications and the importance of testing them.

Demonstration of a component test on a Basket Component using Angular signals.

Explanation of using signals for local change detection and as inputs in Angular components.

Detailed walkthrough of testing a component with signals, focusing on interaction and DOM verification.

Techniques for testing signal effects and computed properties within Angular components.

Strategies for accessing and testing Angular services that utilize signals.

Demonstration of how change detection triggers signal effects and the importance of manual triggering in tests.

Explanation of how effects depend on change detection for execution in Angular applications.

Distinction between testing components with DOM interaction and testing services using signals.

Use of TestBed and fixture for setting up Angular component tests with signals.

Approach for testing the execution of effects multiple times and ensuring correct behavior in Angular.

Refactoring a complex Angular component by moving logic to a service to simplify testing.

Introduction to the flush effects command for manually triggering effects in service tests.

Summary of key points in testing Angular applications with signals, focusing on change detection and manual effect flushing.

Offer of an Angular testing workshop by the speaker, an Angular trainer and consultant.

Transcripts

play00:05

so signals have been introduced in

play00:06

angular as a developer preview in

play00:08

version 16 at the time of this video we

play00:11

are at

play00:13

17.1 and we have already exclusive

play00:15

features that come with signals which is

play00:18

the local change detection and the

play00:19

signal inputs with 17 the signal

play00:23

function the computed function both got

play00:26

stable and the effect function is still

play00:28

in a developer preview but nevertheless

play00:31

we have already some advantages that we

play00:33

can gain from them and it's time to

play00:36

think about integrating into our

play00:38

applications and it also means we need

play00:40

to be able to test them what do we have

play00:43

to be aware of are there some things

play00:45

that we have to be very careful about so

play00:47

these are the things that I want to

play00:48

discuss here in this video okay so this

play00:51

is the component that we want to test

play00:53

it's basket component we have your two

play00:55

different products and as you can see it

play00:58

also comes with the total price

play01:00

now if I click on ADD or on decrement

play01:03

increase or decrement then we see that

play01:05

the total is changed here as

play01:07

well another way how the implementation

play01:10

works is that we have here our basket

play01:14

component so that's this one quite a lot

play01:16

of template there but in the end in the

play01:20

typescript class we have here the

play01:22

product which is a signal containing all

play01:24

the products which we have seen we also

play01:27

have here a sync service that's a

play01:30

service which should do some kind of

play01:33

synchronization stuff as soon as the

play01:36

products change and that's why we have

play01:38

here an

play01:39

effect so every time those products

play01:42

change the sync service is executed with

play01:44

the sync method and then we have here

play01:47

our total price the total price just

play01:50

calculates yeah the total price and it

play01:52

is implemented in the form of a computed

play01:56

as we see here and at the very end of

play01:58

course we also have our decrease our

play02:00

increase methods and what they do is

play02:03

that they call products update and then

play02:05

they just increase the amount of the

play02:07

particular product or decrease it now I

play02:11

want to test this so this is all based

play02:12

on signals and since this is a component

play02:16

we will start or we will do a simple

play02:19

component test that means I need to say

play02:23

test bed configure testing

play02:26

module and in there I am importing

play02:30

my basket component because it is a

play02:33

standalone component and then I say

play02:36

create component basket component again

play02:39

and I store the result in the fixture so

play02:42

I have now my component

play02:44

fixture what we usually always have to

play02:46

do in the very beginning when a

play02:47

component has been created we need to

play02:50

instantiate it we need to make sure that

play02:51

all the life cycle hooks start and that

play02:53

stuff so that's why we call here fixture

play02:56

detect

play02:58

changes and now we can already verify if

play03:02

the total price is is calculated in the

play03:04

right way so since this is a component

play03:06

here I'm not going to directly access

play03:10

the component instance typescript class

play03:13

but I'm really interacting with the

play03:14

component via the D which means I will

play03:17

click on the button I will not call the

play03:19

event listener method and I will also

play03:22

not verify against the property against

play03:25

the signal property but um against those

play03:28

things which are rendered in the

play03:31

and maybe we start with that one first

play03:33

so I say I need to now fetch somewhere

play03:36

the total price from the Dom so I use

play03:38

here my fixture again I say debug

play03:41

element I say query with query I have

play03:44

the possibility to use spy CSS means I

play03:47

can select something with the help of

play03:49

the CSS selectors and then because my

play03:52

total price has attached a data test ID

play03:55

attribute which makes it uniquely to

play03:58

select I can say yeah there is a data

play04:00

test ID attribute which has the value

play04:04

total and this I want to then fetch the

play04:07

native element and I want to store this

play04:10

into the variable called total and this

play04:13

is a HTML diff

play04:17

element and if everything works I can

play04:20

now verify if my total the Dom element

play04:26

if I'm able to type it has a text

play04:28

content with the value 18 it's a string

play04:33

it's of course not the number it's a

play04:34

string we are here accessing the HTML so

play04:38

I rerun my

play04:40

test need to rerun the right test and we

play04:43

see it is working and the next step now

play04:46

is that I increment the first product so

play04:50

I need to click on the button so let's

play04:52

quickly check out what kind of button or

play04:54

how we can access this button so we have

play04:57

here the button increase and that's the

play04:59

data test ID so again I can use the same

play05:01

selector approach that I've used

play05:05

before so I say yeah this is the the

play05:09

same fixture debug element this time

play05:12

it's button

play05:14

increase and yeah I click directly on

play05:17

the native element I don't need to store

play05:19

it into a variable or

play05:21

something if that has been done then

play05:24

internally the total price should be

play05:27

recalculated which means I need to

play05:29

trigger now the change detection so that

play05:31

my dom gets updated with the current

play05:34

value that's why I say here detect

play05:37

changes and then I can copy my assertion

play05:42

again and I leave it with 18 because I

play05:45

would expect that it's now 21 the coffee

play05:48

costs €3 and it should be 21 which means

play05:51

that the test now is supposed to

play05:58

fail yeah which sh us so it's

play06:02

21 so we see in comparison to a

play06:06

component test without any signals

play06:08

there's not that much difference what's

play06:10

missing though is the effect so that the

play06:13

the the total price is the computed and

play06:15

the effect is still missing we see

play06:17

already the effect in the console log

play06:19

here because it is also executed two

play06:22

times and it's just print the product to

play06:25

our

play06:26

lock so what I want to do now is that I

play06:28

want to verif y that the effect function

play06:31

or the function inside of the effect is

play06:33

executed two times how do I do that I

play06:37

need to get access to this sync service

play06:40

that we've created so I say here testb

play06:44

inject sync service the sync service is

play06:48

provided in root so I just can say

play06:50

inject and I will get the original right

play06:53

out right

play06:55

away so I'm going to store this here so

play06:58

sync service and I will now create a spy

play07:02

on it because otherwise I can't know how

play07:05

often it was executed so I say I have my

play07:09

spy and that's spy on on the sync

play07:13

service and I say whenever the sync

play07:16

method is called I want this information

play07:19

to be stored in the Spy variable

play07:21

Bell good so now I need to find out

play07:24

those places in my code when the Spy was

play07:28

executed we can already say after the

play07:32

first change detection the effect is

play07:35

already executed for the first time

play07:38

again I will make it a little bit

play07:40

different I will let the test fail first

play07:42

to verify that the test is really doing

play07:44

what it is supposed to do so I say here

play07:47

before detect changes

play07:50

spy to have been called one time and

play07:53

this should not fail because the Spy

play07:55

wasn't

play07:58

called and it fils right so called two

play08:01

called zero times now I'm moving it

play08:04

after the change

play08:06

detection let's rerun

play08:09

it and the test is working successful so

play08:12

that means that with the change

play08:13

detection the effect and not just the

play08:15

computed but also the effect is also

play08:19

executed and this is already very

play08:22

important uh to understand what happens

play08:24

here because the effect and the same in

play08:27

a way is true for the computer but

play08:29

especially for the effect the effect has

play08:33

to be triggered by somebody and at the

play08:37

moment in angular because we don't have

play08:38

any signal components yet that's still

play08:41

the change detection so every time the

play08:44

change detection is executed it also

play08:46

goes to the effect and says under the

play08:49

condition that you are dirty please

play08:52

rerun your inner

play08:53

function what does mean dirty dirty

play08:57

means that the effect is is aware of all

play09:00

its depending signals and it knows at

play09:04

any point in time if one of these

play09:06

depending or dependent signals have been

play09:09

changed but it's not executing the side

play09:12

effect right away it relates that

play09:14

somebody comes to it in a way and says

play09:17

yeah now it's time rerun if you're dirty

play09:20

and in our case again that's the change

play09:24

detection that has a consequence the

play09:27

consequence is if I'm running now the

play09:30

change detection a second time against a

play09:33

clean a not dirty effect then it will

play09:37

not have any effect so the the the the

play09:40

the function internally will not be

play09:42

executed so if I would now think well

play09:45

detect changes is running the effect the

play09:47

second time I'm wrong so if I say here

play09:49

two and I rerun the

play09:52

test we will see that the test is going

play09:55

to fail because it was just executed one

play09:57

time that is important to to understand

play09:59

and to

play10:00

remember so when is it executed a second

play10:04

time well when the change detection runs

play10:07

yeah that's still necessary but also

play10:09

when the effect became dirty and that's

play10:12

when the products have changed which

play10:14

means after I have clicked on this

play10:17

native element

play10:19

there and again I could not say okay I

play10:22

put it here right after the click should

play10:25

happen synchronously so the effect

play10:28

execution should happen right after a

play10:30

change to the signal happened but again

play10:33

that's not the case somebody needs to

play10:36

trigger the effect the effect of course

play10:39

knows right now that the products have

play10:42

been changed but it's still waiting that

play10:44

somebody triggers it so I need to move

play10:47

it right here now if I rerun it the test

play10:51

is working good so there are some some

play10:54

things you you have to remember but in

play10:57

the end if you just run the changes as

play11:00

you would normally run it then you don't

play11:02

really face any difficulties when it

play11:05

comes to the effect and to the computed

play11:07

as long as you're working directly with

play11:10

with the do as long as you have change

play11:12

detection which is of course something

play11:14

you don't have if you test a

play11:17

service which is what we're going to do

play11:21

now so I have now the idea that I say

play11:25

yeah the component the basket component

play11:27

here that's quite huge so it has already

play11:30

quite a lot of template and also a

play11:32

little bit of logic I want to move the

play11:34

logic into a separate service so I'm

play11:37

going to take all of that code I'm going

play11:40

to copy it or cut it out we have here

play11:43

already our basket

play11:45

service I put it in there and so what

play11:49

our component has to do now is that it

play11:51

only needs to inject this basket service

play11:55

so it says here inject basket service

play11:59

and then of course we need to access we

play12:01

need to provide expose the properties of

play12:04

the basket service now for the template

play12:07

so I say well there are the products and

play12:09

that's the basket service so I access it

play12:12

like this then we have also our total

play12:15

price I also provide it like this and

play12:18

then I need to provide the two functions

play12:20

for increment uh increase and and and

play12:23

decrease the amount of

play12:26

products so I say here increase function

play12:29

is a number and

play12:32

please um call basket service increase

play12:38

ID and then we also have here

play12:42

decrease where I am doing the

play12:45

opposite good well that's the

play12:48

refactoring and one of the nice side

play12:50

effects when you have tests is that you

play12:53

can now check if the if the basket

play12:55

component is still working as it is

play12:57

supposed to be uh so I need to rerun the

play13:00

test and we see it screen so didn't

play13:02

introduce any Buck basket component is

play13:04

still working but now I say okay basket

play13:09

component is one thing I want to test

play13:11

only the basket component H sorry the

play13:14

basket

play13:15

service so I go into my into back into

play13:18

my test and I say it should test the

play13:22

basket

play13:24

service now because I don't work now

play13:28

against the component I don't need to

play13:31

say create component I will also not get

play13:33

my component fixture I will also

play13:35

therefore not get access to change

play13:37

detection um so I need to find another

play13:40

way but in order to get access to the

play13:43

basket service it's very easy I just

play13:46

have to say tpad inject inject basket

play13:49

service basket service is provided in

play13:51

root it has just one dependency to the

play13:54

sync service which is also provided in

play13:56

rout so I don't need to do anything else

play13:59

in except seeing here inject and I'm

play14:01

getting access to the original

play14:04

services so basket service

play14:07

here and then basket Service uh sync

play14:10

service

play14:14

there so and now let's start with the

play14:19

total price first the easy one that

play14:22

computed when the basket service is

play14:24

instantiated that means that obviously

play14:27

the total price

play14:29

also needs to have already a value so

play14:32

that means if I say here expect basket

play14:35

service and I access the total price and

play14:38

I access it by requesting the current

play14:41

value then I can say well it should be

play14:44

18 yeah let's say 21 because I want to

play14:47

see the test

play14:50

failing so I rerun

play14:54

it and the test is failing because it's

play14:56

18 great

play14:59

so I say here 18 good now I say I want

play15:02

to increase it so I say basket service

play15:06

increase

play15:07

one and again I hope that the test is

play15:10

now failing because it should be 21 and

play15:12

not

play15:14

18 let's rerun

play15:17

it yeah fine it's 21 good nothing really

play15:21

spectacular nothing really new that just

play15:24

works again why is there something we

play15:27

have to be aware of

play15:29

kind of as I said or as explained before

play15:31

the computed works in the same way as

play15:33

the effect it needs to be triggered by

play15:37

somebody and otherwise I mean we can't

play15:40

really say it's it's not running because

play15:42

there is no side effect so in general

play15:44

when it comes to computed signals it's

play15:47

very easy to test them because you just

play15:49

need to call them and you get the

play15:51

current

play15:52

value but for signals it's different so

play15:55

if sorry for for for for the effect it's

play15:58

different because if I now come up here

play16:00

with a spy again and if I

play16:03

say spy on the sync service and I'm now

play16:09

um going to the to the sync method again

play16:11

and I say well let's start let let's go

play16:14

to the very end and we know that since

play16:18

the computed was also executed well the

play16:21

effect should also have been executed so

play16:23

my spy should have been called Two Times

play16:26

by

play16:27

now let's

play16:31

see no wasn't run at all not good so the

play16:35

effect was never

play16:37

executed and again that's the main

play16:39

that's the problem here because there is

play16:41

no change action there is no one there

play16:43

which triggers it unfortunately we also

play16:46

don't have the possibility like with

play16:48

computed that we can access that effect

play16:52

on our own there is no possibility to

play16:55

call an effect as it is with computed

play16:59

so it's not very easy but there is of

play17:03

course a solution because otherwise I

play17:05

wouldn't have done the video and the

play17:07

solution here is flush effects so that's

play17:10

a test that's a method which is provided

play17:13

to you via the test bed and that is

play17:16

doing exactly what the change detection

play17:18

is doing for the effect namely it says

play17:20

if the effect is dirty run

play17:23

it but of course I need to know when to

play17:26

call this command I can't just call it

play17:28

somewhere the effect needs to be

play17:31

dirty so I can start from the very

play17:33

beginning so I say here um not the flush

play17:37

effects that's the that's the name of

play17:39

the command and since total price was

play17:42

already already had already did the the

play17:44

value 18 um with flash effects the same

play17:48

is true also for the effect it is also

play17:50

dirty in the very beginning so if I say

play17:52

here flush it should have been executed

play17:54

one

play17:55

time I can rerun it

play18:00

test working and again the same rules

play18:02

that we have seen before with the change

play18:04

detection apply here as well it needs to

play18:07

be a dirty effect just running flush

play18:10

effect doesn't is not enough so if I say

play18:13

here again flush effect a second time

play18:16

and I would expect that now the Spy has

play18:19

also been executed a second time that's

play18:22

not the case it's just called one

play18:25

time good so I need to place the test B

play18:28

flush effects for the second time where

play18:30

it belongs to and that's right after the

play18:32

increase after the product signal was

play18:36

changed and then it will work so if I

play18:39

then move the to have been called here

play18:43

um also after the flash effects we will

play18:45

see that now the test is working as

play18:48

well so summary as long as we are

play18:52

writing tests that interact with the Dom

play18:55

where change detection is included we

play18:58

don't see any real difference when it

play19:00

comes to signals or maybe to be more

play19:02

precise with effects but if you but if

play19:05

we're testing services where we don't

play19:07

have a change detection then we need to

play19:10

flush the effects manually and that's

play19:12

why the flush effects command and we

play19:15

also have to remember flush effects only

play19:17

works if the effect is dirty otherwise

play19:20

it has no

play19:22

effect by the way you can also use the

play19:26

flush effect in the D base so-called

play19:29

tests as well that would also work here

play19:31

instead of running fixture detect

play19:33

changes but yeah I mean if you have

play19:36

already a Dom based test where you have

play19:39

already to run the tange detection why

play19:42

do you actually want to use flush

play19:43

effects that doesn't make sense so that

play19:46

was it already by the way my name is R

play19:48

Hamp I'm trainer and consultant at

play19:50

angular Architects and if you're

play19:53

interested if you want to learn more

play19:54

about testing in angular and maybe our

play19:56

testing Workshop is exactly what you're

play19:58

looking

play20:00

for I would say thank you very much for

play20:02

watching if you like this video please

play20:05

give it a like also subscribe to my

play20:07

channel and of course if you have any

play20:09

questions then just ask thanks again and

play20:12

see you in the next video goodbye

Rate This

5.0 / 5 (0 votes)

Related Tags
Angular 17.1Software DevelopmentComponent TestingAngular SignalsChange DetectionComputed FunctionsEffect FunctionsSync ServiceDeveloper PreviewProgramming Tutorial