Very informative, thank you. I had not heard about the Moq controversy, so thanks also for pointing that out. It does seem to have caused damage to the library's reputation because of the silent implementation.
When retrofitting tests on existing code as shown, rather than doing TDD, it's always handy to deliberately break the code under test after you get each test passing. In this case by removing the return in the branch your presuming is being hit, to verify that your test is actually testing the code you think it is.
Here you have unique errors for each scenario and they are used once in the code, this good design helps reduce the need for my above suggestion but in a general sense it's still a good way to double-check your tests.
Hi Milan, What do you think about using ASP NET Identity with Clean Architecture rich domain models? Or Its better to implement our own authentication workflow without ASP NET Identity in clean architecture?
Why are you doing the last test verifying if the repository inserted the follower, checking if the method of the repo was called? Seems like you are getting coupled to the implementation of the method. Couldn't you make the follow method return the Followed entity instead and assert instead that the entity has the expected properties?
What about testing that an insertion with EF Core made the correct database entry? And a step further, what about checking this on a real (testing) database?
These tests from my point of view are fragile. If you refactor at some point your repository interface you will be breaking them, why not testing it like the user would use your api? Just instantiate your webapplicationfactory and send requests to it. Also, the use of the builder pattern is useful for creating entities/value objects. You could avoid having at the top of your test class some useless private readonly fields. I hope this helps you, and thanks for the video 🙂
@@MilanJovanovicTech No. I also write unit tests, but mainly I run them for the domain layer + parts of a feature that cannot be tested through functional tests
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
I also starting using NSubstitute because of the that controversy. I have to say, that now, I even prefer it over Moq.
The functional approach is nice
Very informative, thank you.
I had not heard about the Moq controversy, so thanks also for pointing that out. It does seem to have caused damage to the library's reputation because of the silent implementation.
I can't remember what was it about? Ads or telemetry?
Ads (if I recall correctly)
When retrofitting tests on existing code as shown, rather than doing TDD, it's always handy to deliberately break the code under test after you get each test passing. In this case by removing the return in the branch your presuming is being hit, to verify that your test is actually testing the code you think it is.
Here you have unique errors for each scenario and they are used once in the code, this good design helps reduce the need for my above suggestion but in a general sense it's still a good way to double-check your tests.
Ah you touched on it later in the video in passing when verifying the repo. 😊
A nice summary of the video through this short thread 😁
bro is showing facts 👑
✅
it is very useful video, thank you Milan
You're welcome :)
Hi Milan, What do you think about using ASP NET Identity with Clean Architecture rich domain models? Or Its better to implement our own authentication workflow without ASP NET Identity in clean architecture?
Will try do a video about it soon :)
Why are you doing the last test verifying if the repository inserted the follower, checking if the method of the repo was called?
Seems like you are getting coupled to the implementation of the method.
Couldn't you make the follow method return the Followed entity instead and assert instead that the entity has the expected properties?
That could be an improvement
Awesome video!
Thanks
Which Reault class are you using Milan?
I create my own
Thanks
Sure thing :)
Amazing video!
What do you think about specflow ?
Where we define the BDD and create functions for the tests
Haven't tried that out
What about testing that an insertion with EF Core made the correct database entry? And a step further, what about checking this on a real (testing) database?
Falls under integration testing: czcams.com/video/tj5ZCtvgXKY/video.html
These tests from my point of view are fragile. If you refactor at some point your repository interface you will be breaking them, why not testing it like the user would use your api? Just instantiate your webapplicationfactory and send requests to it. Also, the use of the builder pattern is useful for creating entities/value objects. You could avoid having at the top of your test class some useless private readonly fields.
I hope this helps you, and thanks for the video 🙂
Do you only write functional-style tests like that?
@@MilanJovanovicTech No. I also write unit tests, but mainly I run them for the domain layer + parts of a feature that cannot be tested through functional tests
How about in VSA?
What about it?
@@MilanJovanovicTech I mean how to implement Unit Testing in VSA
👋👋