THIS stops 90% of C# Developers Learning TDD
Vložit
- čas přidán 12. 12. 2022
- ⭐️ Use the coupon code GUITDD to get a 20% discount course on my new TDD course: dometrain.com/course/from-zer...
90% of C# Developers stop learning TDD for the same reason.
And that is because introductory videos say nothing about how to deal with real-world complex scenarios, like working with external dependencies.
So, to help you overcome this, let's see how to apply test-driven development on common use cases like Services that have external dependencies like Repositories.
🚨 KEY LINKS
🤝 Support me on Patreon (and get access to source code) here: / gsferreira
👋 HEY FRIEND
If you're new to my Channel, my name is Guilherme, but you can call me Gui if Portuguese pronunciation is not your thing.
I see myself as a Minimalist Software Craftsman. That says a lot of what I talk about here.
So, why this CZcams channel? To share with you to simplify your life as a Developer through knowledge, technology, and practices.
If you are into those things as I do, don't forget to subscribe for new videos.
🔗 GET IN TOUCH
LinkedIn: / gferreira
Twitter: / gsferreira
GitHub: github.com/gsferreira
Visit my blog: gsferreira.com
#dotnet #csharp #tdd #testdrivendevelopment
Wow, this is by far the most useful tutorial on TDD I have ever seen on CZcams. I appreciate it.
WOW! Thanks. You made my day 🙏
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.
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.
"including my own..." I automacally engage with that video..3,2,1...
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 😜
I like his fast pace - finally an example of real use of TDD.
Thank you Johnny!
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 😅
czcams.com/video/uaN7SG8IYq4/video.htmlsi=QzzM0Y9uf5DzfgXl
good content, even though I never coded c#, java for now, it's useful for showing the mindset and approach.
Glad to hear that! 🙏
Incredibly useful will use what I've learnt for my e-commerce project
Thanks! Glad to hear that 🙏
When you practice TDD, you should not constantly switch to coding/generating your unit. Your initial test run should be red, not green.
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.
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.
Loved the vid as soo many don’t use TDD to guide their design. For anyone that likes this really consider NCrunch as it makes this approach a blast (however AFAIK) Rider is unfortunately not an option with that, but if you like Visual Studio it is awesome for this flow as you get instant feedback with coverage on top.
Thanks, Mirko. I don't have experience with NCrunch but I think that continuous testing has the same goal.
www.jetbrains.com/help/rider/Work_with_Continuous_Testing.html
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?
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.
Finally somebody beyond "function takes argument"
Great tutorial 🙌
Thank you Brian 🙌
Make sense. Could you create video about TDD on repository layer
It's on the pipeline Eldho 😉
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.
@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
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
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!
Which colour scheme are you using?
Hi! Dracula for Rider
plugins.jetbrains.com/plugin/12275-dracula-theme
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.
czcams.com/video/D0dCa9XO4z0/video.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 😜
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 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.
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.
database is not outside of your control, you dont need to mock access to it
It depends. One example: If you value feedback cycle quick iterations.
@@gui.ferreira it does not depend, you can quickly setup in-memory database, no excuses
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: czcams.com/video/D0dCa9XO4z0/video.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.