THIS stops 90% of C# Developers Learning TDD

[@alpsavasdev]

Wow, this is by far the most useful tutorial on TDD I have ever seen on KZbin. I appreciate it.

[@gui.ferreira]

WOW! Thanks. You made my day 🙏

[@johnnyserup5500]

I like his fast pace - finally an example of real use of TDD.

[@gui.ferreira]

Thank you Johnny!

[@GavinHohenheim]

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..

[@gui.ferreira]

Thanks! One of the goals of TDD is to produce executable documentation. I don't like documentation that is hard to read 😜

[@MarcusHammarberg]

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.

[@gui.ferreira]

Thank you! That "dreaming" phase is often ignored but is precious.

[@aweklin]

This approach makes you run smoothly, with little debugging because you saw through behaviours as you develop! Love this & thanks for sharing.

[@gui.ferreira]

Indeed, Akeem!

[@minecraftwithdan]

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 😊

[@gui.ferreira]

I'm so glad it helped! Thanks, David!

[@FroboDaggins]

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.

[@gui.ferreira]

Thanks! Give it a try. You will see that it pays off.

[@chazzman4553]

Just started c#, switching from php 😊. Very helpful channel! Thanks man.

[@gui.ferreira]

Thanks, Chazz! 🙏 Good luck on your journey! I hope you like C# as much as I do.

[@rezvlt9285]

Incredibly useful will use what I've learnt for my e-commerce project

[@gui.ferreira]

Thanks! Glad to hear that 🙏

[@martinmusli3044]

Finally somebody beyond "function takes argument"

[@PaulSebastianM]

When you practice TDD, you should not constantly switch to coding/generating your unit. Your initial test run should be red, not green.

[@MrOcelot92]

good content, even though I never coded c#, java for now, it's useful for showing the mindset and approach.

[@gui.ferreira]

Glad to hear that! 🙏

[@Kamuisakeu]

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!

[@gui.ferreira]

I have a video about that 😅 kzbin.info/www/bejne/q5KxaIZ9ba6Mp5Ysi=QzzM0Y9uf5DzfgXl

[@PaulSebastianM]

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?

[@yonkocarly]

"including my own..." I automacally engage with that video..3,2,1...

[@PeteSauerbier]

Good tutorial indeed. Quick question, why didn't you put the context initialization for your tested class into a setup?

[@gui.ferreira]

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.

[@wolfgang999]

what are the advantages of using fakes instead of moqs ?🤔

[@gui.ferreira]

May I suggest taking a look at this video? I think I address that question there. kzbin.info/www/bejne/emHHdJRvjbRnsJI

[@enzopowell9234]

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]

The famous bang-bang "!!" operator was removed from the release. The feature didn't resist the community backlash

[@enzopowell9234]

@@gui.ferreira damn, I think this feature is nice. Not sure why it was the backlash

[@gui.ferreira]

@@enzopowell9234 Due to the community voice 😜

[@Dalamain]

Too sad Dart died overnight.

[@enzopowell9234]

@@Dalamain Dart died?

[@SimonLomax-qw3dv]

Which colour scheme are you using?

[@gui.ferreira]

Hi! Dracula for Rider plugins.jetbrains.com/plugin/12275-dracula-theme

[@teamtosoz892]

why is this better than let's say use schemathesis and test based on the openapi specification ?

[@gui.ferreira]

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.

[@eldhoabe8556]

Make sense. Could you create video about TDD on repository layer

[@gui.ferreira]

It's on the pipeline Eldho 😉

[@diegomelgar2696]

Id like to see the repositories and also an integration test video example 😃

[@diegomelgar2696]

Using factories, faker, seedeing, migrations too! Would appreciate

[@gui.ferreira]

Good ideas here. Thanks Diego!

[@sebastienvandepoel1377]

Great video. I just was wondering, why didn't you start with the happy path? Is there any reasoning behind it?

[@gui.ferreira]

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?

[@sebastienvandepoel1377]

Yes, it does. I was always starting with the happy path. But now I will question myself before starting my tests. Thanks

[@kitsurubami]

I feel like I should re-watch this video 50 times until it really sinks in.

[@gui.ferreira]

I'm not sure how I should feel about that. 😅

[@kitsurubami]

@@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.

[@gui.ferreira]

@@kitsurubami Let me know if something is not clear and I will try to help.

[@kitsurubami]

@@gui.ferreira Thank you. You are very kind.

[@BrianHeunis]

Great tutorial 🙌

[@gui.ferreira]

Thank you Brian 🙌

[@ActionReaction..]

what stops most of us from doing TDD is our customers their budget 😂

[@gui.ferreira]

You are assuming that TDD takes more time than not testing 😉

[@Grassyfieldsflowers]

TDD and acceptance testing done right is an investment which pays back after a few weeks or months. It certainly does slow you down initially as it forces you to think more before you write code and it forces you to clean up that code as you go. However this pays off through the duration of the project as you spend less time fixing bugs as you more often catch these earlier on in the development.

[@MrMattberry1]

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.

[@Grassyfieldsflowers]

Fakes are actually far more maintainable than mocks as the tests are not coupled to the interfaces and they actually have real fake implementations, I.e. if I add an item my code can also get that same item from the fake. If I using a dynamic mock, I have to create another setup for the add and the get and ensure I pass the correct data, they also result in coupling of the test cases to the interface your mocking. You’ll know it when you encounter a case of coupled test shotgun surgery it’s the fast way to put you developers off test driven development, when all your tests break because you updated an interface, everywhere you did a mock.setup you need to go and fix this. This problem doesn’t exist with fakes, just update the implementation of the fake issue resolved, tests don’t need updating.

[@swarupmahapatra1]

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

[@gui.ferreira]

In this case, I'm using a Fake instead of a Mock. I have a video on Test Doubles if you want to check: kzbin.info/www/bejne/emHHdJRvjbRnsJI 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.

[@marna_li]

@gui.ferreira Yeah! Bravo! This was what I was looking for. Someone showing how to think when building software with testing in mind.

[@gui.ferreira]

WOW Thanks Marina! After your comment on the other video, I'm happy to find this one 😉

[@marna_li]

@@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.

[@gui.ferreira]

@@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.

[@marna_li]

@@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! 🙂

[@gui.ferreira]

@@marna_li thank you once again

[@PaulSebastianM]

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.