Explore all the potential of WallabyJS 2.0 with a free trial 🚀 wallabyjs.com/?referrer=DecodedFrontend2024 🔥 Angular Unit Testing Course - bit.ly/angular-testing-course
Thank you very much for reviewing such important topic. I wanted to add my 5 cents. 😅 For the last case with subscription to the Observable we can also utilize a done function, which will should be called within a subscription after expect block. In this case test will wait untill the done function is called, thus the assertion will be executed and only after that the test case will be considered as executed. I found writing tests this way with some asynchronous tasks makes you more in control of the flow and makes it more explicit on when it is really considered as "done" 😉
I love your content, great value ! About testing only the "class", I think it's not useless, especially if you have an e2e testing strategy. Shai calls it isolation tests, and no it will not test the whole application, but honestly, no tests will.
Hi Alain, Thank you for your comment and your kind words about my channel :) Could you please clarify what do you mean by "e2e testing strategy"? Because my understanding of "e2e strategy" is when you are testing entire application including all dependencies, backend, network, etc. and fairly speaking I don't get how class-only tests fit this concept. To me it doesn't even sound technically possible :) But maybe I am missing something or did you mean something else? I can not speak from Shai, but I believe by saying "isolation tests" he means "unit tests" because usually these 2 terms are used interchangeably. Yes, isolated (unit) tests indeed do not test whole application, and they must not to do that because it is responsibility of e2e tests. Unit tests verify only the behaviour of 1 single unit (component/directive/pipe/etc) assuming that unit dependancies are working as expected. On practice we achieve that by mocking dependencies. In e2e tests we mock nothing and test everything as it is. This is the whole difference. The important take, however, is that in both type of tests we should simulate behaviour/interaction of user as close as possible to make the tests reliable and this is exactly what class-only unit tests fail to do because they lack of that interaction layer. I hope I could make it a little bit clear :)
@@DecodedFrontend Yeah, sorry for the confusion, I didn't mean that we would make e2e tests through our unit tests. I mean : if you have some e2e tests in your app, and they can be in an integration environment, maybe even with mocked api, you could skip probably completely the DOM tests in your unit tests. Then you could focus on testing your algorithms, all the pure functions that exist in your components and services and pipes, whatever. I like the class testing for angular components because I think that most of the time, the user actions are very "partial", when you test a single component, so many things happen that never come from the user actions, or maybe very indirectly. I hope I myself am a little bit clearer :) Anyway, I like to see other strategies, because these concepts and technologies keep evolving !
Subsribe inside tests could lead into problems in CI pipelines if those observables relies on time. I prefer using marbles in these cases, much clear and simple.
Thank you for your comment :) I would actually argue if done,() would be a better solution :) done() will block the execution of tests until it is called. If it is never called, the test will fail only after some timeout 5/10/20 secs which is not good because you want tests failing asap to not waste resources of your CI pipeline. If async stuff is involved, I would probably go with something like fakeAsync :)
@@DecodedFrontend do you have some material on fakeAsync, waitForAsync etc.? I'm not very confident in using them. I've seen them and know the documentation, but my knowledge can be improved... 🥸
great video thank Dmytro, the last test confused me, you're subscribing and then you change the value inside the function, subscribe is like a promise, how can you make the assertion in the last sentence?
Hey Harold, this is a great question. The thing is that outputs are synchronous which means that .subscribe(…) will be executed as part of the emit() method call stack, so that’s why the execution will be in the order that is slightly different from how it is written in code.
Could you compare when is it better to have an input per property vs a single input containing an object with all properties inside? In your sample code here you used the latter; single input passing data object
I would freakin' love more videos about testing with angular, maybe with some complex scenarios as well, Like dealing with a combination of observables, promises and timers with services. Also in the project that I work on I developed a master detail component which has a form on 1 side as a component and another separate component on the detail side which is opened with a keybord shortcut, and has a interactive grid, I'm not sure how will I go about testing this type of stuff.. 😁
Thank you for your comment :) Hard to say something concrete about your use case without seeing the component itself :( Just as a idea to make integration tests if those 2 components are working as "one system". But again, it is just an idea/thoughts.
Yeah, indeed something went wrong. You can try this link - bit.ly/course-angular-testing Link in the description was also updated. Sorry for inconvenience
Explore all the potential of WallabyJS 2.0 with a free trial 🚀
wallabyjs.com/?referrer=DecodedFrontend2024
🔥 Angular Unit Testing Course - bit.ly/angular-testing-course
Nice. Looking forward to more videos about testing :)
Great as always 🎉
Great Content, appreciate it!
Insightful video💡. All the tips are practical and helpful.
Thank you very much for reviewing such important topic. I wanted to add my 5 cents. 😅
For the last case with subscription to the Observable we can also utilize a done function, which will should be called within a subscription after expect block. In this case test will wait untill the done function is called, thus the assertion will be executed and only after that the test case will be considered as executed. I found writing tests this way with some asynchronous tasks makes you more in control of the flow and makes it more explicit on when it is really considered as "done" 😉
Great explanation
Thank you! Nince hints! You never disappoint
Glad to hear that! Thank you :)
Completely agree with the mistake 3
What about others?:)
I love your content, great value !
About testing only the "class", I think it's not useless, especially if you have an e2e testing strategy.
Shai calls it isolation tests, and no it will not test the whole application, but honestly, no tests will.
Yes, we can have test which tests logic of this particular method and another one which tests the whole flow
Hi Alain,
Thank you for your comment and your kind words about my channel :)
Could you please clarify what do you mean by "e2e testing strategy"? Because my understanding of "e2e strategy" is when you are testing entire application including all dependencies, backend, network, etc. and fairly speaking I don't get how class-only tests fit this concept. To me it doesn't even sound technically possible :) But maybe I am missing something or did you mean something else?
I can not speak from Shai, but I believe by saying "isolation tests" he means "unit tests" because usually these 2 terms are used interchangeably. Yes, isolated (unit) tests indeed do not test whole application, and they must not to do that because it is responsibility of e2e tests. Unit tests verify only the behaviour of 1 single unit (component/directive/pipe/etc) assuming that unit dependancies are working as expected. On practice we achieve that by mocking dependencies. In e2e tests we mock nothing and test everything as it is. This is the whole difference. The important take, however, is that in both type of tests we should simulate behaviour/interaction of user as close as possible to make the tests reliable and this is exactly what class-only unit tests fail to do because they lack of that interaction layer.
I hope I could make it a little bit clear :)
@@DecodedFrontend Yeah, sorry for the confusion, I didn't mean that we would make e2e tests through our unit tests.
I mean : if you have some e2e tests in your app, and they can be in an integration environment, maybe even with mocked api, you could skip probably completely the DOM tests in your unit tests. Then you could focus on testing your algorithms, all the pure functions that exist in your components and services and pipes, whatever.
I like the class testing for angular components because I think that most of the time, the user actions are very "partial", when you test a single component, so many things happen that never come from the user actions, or maybe very indirectly.
I hope I myself am a little bit clearer :)
Anyway, I like to see other strategies, because these concepts and technologies keep evolving !
Subsribe inside tests could lead into problems in CI pipelines if those observables relies on time. I prefer using marbles in these cases, much clear and simple.
For 5th mistake, we handled it using Jasmine done callback. But your solution is much more better and easy.
The "done" callback would be better, if there's some async stuff going on in the background or implementation of the output.
Great video as always!
Thank you for your comment :) I would actually argue if done,() would be a better solution :) done() will block the execution of tests until it is called. If it is never called, the test will fail only after some timeout 5/10/20 secs which is not good because you want tests failing asap to not waste resources of your CI pipeline. If async stuff is involved, I would probably go with something like fakeAsync :)
@@DecodedFrontend do you have some material on fakeAsync, waitForAsync etc.? I'm not very confident in using them. I've seen them and know the documentation, but my knowledge can be improved... 🥸
As free material, unfortunately, no :( But maybe I will do in the future :)
make an video of ngrx signal store & how to make api calls with in it with help of rxjs functionalites
Added to the list ;)
great video thank Dmytro, the last test confused me, you're subscribing and then you change the value inside the function, subscribe is like a promise, how can you make the assertion in the last sentence?
Hey Harold,
this is a great question. The thing is that outputs are synchronous which means that .subscribe(…) will be executed as part of the emit() method call stack, so that’s why the execution will be in the order that is slightly different from how it is written in code.
@@DecodedFrontend ok, thanks
Could you compare when is it better to have an input per property vs a single input containing an object with all properties inside? In your sample code here you used the latter; single input passing data object
I would freakin' love more videos about testing with angular, maybe with some complex scenarios as well,
Like dealing with a combination of observables, promises and timers with services.
Also in the project that I work on I developed a master detail component which has a form on 1 side as a component and another separate component on the detail side which is opened with a keybord shortcut, and has a interactive grid, I'm not sure how will I go about testing this type of stuff.. 😁
Thank you for your comment :) Hard to say something concrete about your use case without seeing the component itself :( Just as a idea to make integration tests if those 2 components are working as "one system". But again, it is just an idea/thoughts.
I opened your testing course from comments and description of this video and it says "Invalid coupon code"
Yeah, indeed something went wrong. You can try this link - bit.ly/course-angular-testing
Link in the description was also updated. Sorry for inconvenience