I love your frequent refactoring of not only the code, but also the tests. Most devs I see complaining about TDD do not understand how important that is..
Thank you so much for this video. Your explanation is so clear and it was exactly what I was looking for to keep on my TDD journey and not get dispondent 😊
Yes! The "Wishful thinking" part of TDD, imaging that the system we wanted to have, is a power tool. I also loved how you used the phrase "put our test into a green state", when we had stuff that didn't compile.
One amazing thing about this tutorial: This video, with all the explanations took almost 20 minutes and delivered a considerable amount of code with solid unit tests. Now imagine doing this with focus, in the flow, using some AI assistance. The productivity will skyrocket!
Great example of how to apply TDD in a realistic scenario. I'd like to try out using fakes more as having the code written prior to the tests means I always tend to end up just using mocks.
That's a good point. Since I'm using xUnit I could do that indeed. I usually like to start with the code in the test method, and when I add more tests in the same class, I extract common setup code to the constructor.
One problem that I have whenever I try to distinguish between behaviour and implementation is what unit am I testing and how do I name my tests and/or test class. ’CreateOrderTests’ does not help me understand the unit it is testing, while it may help me understand the behaviour it is testing. Any thoughts on that?
Excellent question. I always ask myself “Which is the the simplest/smallest step I can take?!”. I don't mind if that is not the happy path. When you use Guard Clauses or follow the principle of return early, often the smallest thing you can do is validate input data. However, when the work is exploratory, it might be worthy to take note of those cases and first implement the happy path, since the direction is not clear. Does it make sense?
If you use nullable reference types, why write tests that check for null arguments? I thought the whole point of NRTs was to remove this boilerplate and the kinds of bugs caused by null.
Hi, I notice that the "shippingAddress" parameter is by default nullable and that's why you need to write test against it. Too sad C# has no null-safety feature like Dart. But now in c# 11, putting "!!" at the end of the name of arguments can let us skip all the if blocks checking for possible null arguments.
@@gui.ferreira I did not dislike you other movie. Just gave my thoughts. And then I found this when looking for your TDD videos 🙂 Another thought: I do not think that anyone should jump into TDD or any other paradigm without truly understand the value it brings to software development. You can not walk before you have crawled. So I encourage people to explore a broad set of topics in SD before applying them in serious professional projects where you initially soon discover your current limits.
@@marna_li I tend to agree with you. TDD is just another approach. What I would say, is that everyone should give it a chance, but that means that once you do it it's important to stick to it for a while.
@@gui.ferreira Sure they should give it a chance. Perhaps people start to think more about how they write their code then. But in general, when it comes to the bigger topics, I don’t think that people should rush to use some architecture or so when building a professional product. Not without experimenting a lot across the field to understand pros and cons. Anyhow, I appreciate you and the other “content creators” who work so hard in educating us, using your knowledge, experience, and interest in the field! 🙂
TDD is not only a testing practice but also a design practice. I think that those tools can eventually be used in an Acceptance Test way in combination with TDD.
@@gui.ferreira I mean that the content of the video is very valuable to learn. At my current experience level, it's a little hard to grasp, but that is my own shortcoming.
I would say there is too much functional code being created for the tests. These fakes could easily have bad code in them, you really need to use mocks.
By introducing `Get` on orderRepository, aren't you making your test depend on `Get`'s implementation? The test may fail if the `Get` is implemented incorrectly. The reason your test will fail is not related to business logic, but a logic introduced by test. Probably this is the case, where mocking (spying) is necessary. To spy the outgoing messages from an object. In the case calling methods on repository . Specially the ones that will create state change , like create/delete/update
In this case, I'm using a Fake instead of a Mock. I have a video on Test Doubles if you want to check: ruclips.net/video/D0dCa9XO4z0/видео.html There's an argument to be made on the need for testing Fakes. However, in my experience, it's often nitpicking as far as your Fakes are extremely simple.
Wow, this is by far the most useful tutorial on TDD I have ever seen on RUclips. I appreciate it.
WOW! Thanks. You made my day 🙏
I like his fast pace - finally an example of real use of TDD.
Thank you Johnny!
This approach makes you run smoothly, with little debugging because you saw through behaviours as you develop!
Love this & thanks for sharing.
Indeed, Akeem!
I love your frequent refactoring of not only the code, but also the tests. Most devs I see complaining about TDD do not understand how important that is..
Thanks!
One of the goals of TDD is to produce executable documentation. I don't like documentation that is hard to read 😜
Just started c#, switching from php 😊.
Very helpful channel! Thanks man.
Thanks, Chazz! 🙏 Good luck on your journey! I hope you like C# as much as I do.
Thank you so much for this video. Your explanation is so clear and it was exactly what I was looking for to keep on my TDD journey and not get dispondent 😊
I'm so glad it helped! Thanks, David!
Yes! The "Wishful thinking" part of TDD, imaging that the system we wanted to have, is a power tool. I also loved how you used the phrase "put our test into a green state", when we had stuff that didn't compile.
Thank you! That "dreaming" phase is often ignored but is precious.
Incredibly useful will use what I've learnt for my e-commerce project
Thanks! Glad to hear that 🙏
One amazing thing about this tutorial: This video, with all the explanations took almost 20 minutes and delivered a considerable amount of code with solid unit tests.
Now imagine doing this with focus, in the flow, using some AI assistance.
The productivity will skyrocket!
I have a video about that 😅
ruclips.net/video/uaN7SG8IYq4/видео.htmlsi=QzzM0Y9uf5DzfgXl
Great example of how to apply TDD in a realistic scenario.
I'd like to try out using fakes more as having the code written prior to the tests means I always tend to end up just using mocks.
Thanks!
Give it a try. You will see that it pays off.
good content, even though I never coded c#, java for now, it's useful for showing the mindset and approach.
Glad to hear that! 🙏
Finally somebody beyond "function takes argument"
"including my own..." I automacally engage with that video..3,2,1...
Good tutorial indeed. Quick question, why didn't you put the context initialization for your tested class into a setup?
That's a good point. Since I'm using xUnit I could do that indeed. I usually like to start with the code in the test method, and when I add more tests in the same class, I extract common setup code to the constructor.
One problem that I have whenever I try to distinguish between behaviour and implementation is what unit am I testing and how do I name my tests and/or test class. ’CreateOrderTests’ does not help me understand the unit it is testing, while it may help me understand the behaviour it is testing. Any thoughts on that?
Id like to see the repositories and also an integration test video example 😃
Using factories, faker, seedeing, migrations too! Would appreciate
Good ideas here. Thanks Diego!
Great video.
I just was wondering, why didn't you start with the happy path? Is there any reasoning behind it?
Excellent question. I always ask myself “Which is the the simplest/smallest step I can take?!”. I don't mind if that is not the happy path.
When you use Guard Clauses or follow the principle of return early, often the smallest thing you can do is validate input data.
However, when the work is exploratory, it might be worthy to take note of those cases and first implement the happy path, since the direction is not clear.
Does it make sense?
Yes, it does.
I was always starting with the happy path. But now I will question myself before starting my tests.
Thanks
If you use nullable reference types, why write tests that check for null arguments? I thought the whole point of NRTs was to remove this boilerplate and the kinds of bugs caused by null.
Make sense. Could you create video about TDD on repository layer
It's on the pipeline Eldho 😉
Great tutorial 🙌
Thank you Brian 🙌
When you practice TDD, you should not constantly switch to coding/generating your unit. Your initial test run should be red, not green.
what are the advantages of using fakes instead of moqs ?🤔
May I suggest taking a look at this video?
I think I address that question there.
ruclips.net/video/D0dCa9XO4z0/видео.html
Hi, I notice that the "shippingAddress" parameter is by default nullable and that's why you need to write test against it. Too sad C# has no null-safety feature like Dart. But now in c# 11, putting "!!" at the end of the name of arguments can let us skip all the if blocks checking for possible null arguments.
The famous bang-bang "!!" operator was removed from the release.
The feature didn't resist the community backlash
@@gui.ferreira damn, I think this feature is nice. Not sure why it was the backlash
@@enzopowell9234 Due to the community voice 😜
Too sad Dart died overnight.
@@Dalamain Dart died?
@gui.ferreira Yeah! Bravo! This was what I was looking for. Someone showing how to think when building software with testing in mind.
WOW Thanks Marina!
After your comment on the other video, I'm happy to find this one 😉
@@gui.ferreira I did not dislike you other movie. Just gave my thoughts. And then I found this when looking for your TDD videos 🙂
Another thought:
I do not think that anyone should jump into TDD or any other paradigm without truly understand the value it brings to software development. You can not walk before you have crawled. So I encourage people to explore a broad set of topics in SD before applying them in serious professional projects where you initially soon discover your current limits.
@@marna_li I tend to agree with you. TDD is just another approach.
What I would say, is that everyone should give it a chance, but that means that once you do it it's important to stick to it for a while.
@@gui.ferreira Sure they should give it a chance. Perhaps people start to think more about how they write their code then.
But in general, when it comes to the bigger topics, I don’t think that people should rush to use some architecture or so when building a professional product. Not without experimenting a lot across the field to understand pros and cons.
Anyhow, I appreciate you and the other “content creators” who work so hard in educating us, using your knowledge, experience, and interest in the field! 🙂
@@marna_li thank you once again
Which colour scheme are you using?
Hi! Dracula for Rider
plugins.jetbrains.com/plugin/12275-dracula-theme
why is this better than let's say use schemathesis and test based on the openapi specification ?
TDD is not only a testing practice but also a design practice.
I think that those tools can eventually be used in an Acceptance Test way in combination with TDD.
I feel like I should re-watch this video 50 times until it really sinks in.
I'm not sure how I should feel about that. 😅
@@gui.ferreira I mean that the content of the video is very valuable to learn. At my current experience level, it's a little hard to grasp, but that is my own shortcoming.
@@kitsurubami Let me know if something is not clear and I will try to help.
@@gui.ferreira Thank you. You are very kind.
what stops most of us from doing TDD is our customers their budget 😂
You are assuming that TDD takes more time than not testing 😉
I would say there is too much functional code being created for the tests. These fakes could easily have bad code in them, you really need to use mocks.
By introducing `Get` on orderRepository, aren't you making your test depend on `Get`'s implementation?
The test may fail if the `Get` is implemented incorrectly. The reason your test will fail is not related to business logic, but a logic introduced by test.
Probably this is the case, where mocking (spying) is necessary.
To spy the outgoing messages from an object. In the case calling methods on repository .
Specially the ones that will create state change , like create/delete/update
In this case, I'm using a Fake instead of a Mock.
I have a video on Test Doubles if you want to check: ruclips.net/video/D0dCa9XO4z0/видео.html
There's an argument to be made on the need for testing Fakes. However, in my experience, it's often nitpicking as far as your Fakes are extremely simple.