How I Would Test-Drive a .NET CRUD API (TDD)

Подписаться 12 тыс.

Просмотров 7 тыс.

50% 1

⭐️ Use the coupon code GUITDD to get a 20% discount course on my new TDD course: dometrain.com/...
I love TDD but practicing it when building a plain old CRUD API, it doesn't sound obvious. In this video, I will show you how I would approach it in a simple and pragmatic way.
💎 Be a Patreon to get the source code: / gsferreira
🚨 KEY LINKS
🤝 Support me on Patreon (and get access to source code) here: / gsferreira
👨‍🏫 TDD Course at Dometrain: dometrain.com/...
👋 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 RU-vid 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/gsf...
Visit my blog: gsferreira.com
#dotnet #csharp #testdrivendevelopment #tdd

Опубликовано:

10 сен 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 21

@Aweklin 2 месяца назад

Great content as always. Thanks a lot for sharing.

@gui.ferreira 2 месяца назад

Glad you enjoyed it!

@krs-tube 9 месяцев назад

Thank you for the video, really quick and easy to follow and understand. What are the other type of tests you were implying when saying - "when things are getting complex"?

@gui.ferreira 8 месяцев назад

Thanks! When it gets complex, I bring Unit Tests around the application code isolating dependencies.

@louisgerard3916 11 месяцев назад

I disagree with this way of testing, because your tests are too coupled to the implementation details (database). Furthermore by doing so, you don’t really test the external behavior, but the internals. In such cases, I prefer to ask the user: why do you want to create a product ? Because I want to keep track of it and be able to list the products later. Then you have your first test: create a product and assert that you are able to find it back when you GET the product list.

@gui.ferreira 11 месяцев назад

I agree with that. If I have the GET in place, I would prefer to use it. When I don't through the public API a way to do it, I find a Fake to keep my tests fast.

@krs-tube 7 месяцев назад

Hey Gui, what's your preferred type of database to use for a simple crud api, assuming imemory ef database not to be a good choice. Which one would be more convenient/easy to setup and use, sql server in a container or sqlite, or something else? Thank you

@gui.ferreira 7 месяцев назад

I’m a huge fan of PostreSQL. Take a look 😉

@F2H16 9 месяцев назад

Hey Gui, I am a great fan of your content. Is it a good idea to use in-memory database while doing TDD? Database is an external dependency hence should not it be handled accordingly ? In-memory DBs come up with handful of features compared to a a full-fledge DB and using it might confuse in terms of expectations or even produce unexpected results. As you have shown in many videos how to use Stubs/ Mocks, I would personally use one of them instead of an in-memory database.

@gui.ferreira 9 месяцев назад

Hey! Thanks for following along 🙏 So, I normally use Test Doubles (Stubs, mocks, etc.). But, it's important to think about "Why do I do it?". Using unstable or slow dependencies is not a good idea if we want to have a successful TDD cycle. You might have noticed in other videos that I often build my own fakes. If you think about that, in this scenario, the in-memory DB is a fake. So, in cases like this, where I don't have any complex logic in place, and the main goal of the service is to act as a kind of proxy in front of a DB, using an in-memory provider brings more value than configuring a ton of mocks. Does it make sense?

@MatheusLB2009 4 месяца назад

The "EF Core In-Memory Database Provider" documentation is pretty clear that it should not be used outside of testing, and no features will be added to it. I think ive read somewhere that it should only be used for legacy reasons. Ide refrain from using it altogether, use SQLite instead Also, since its in memory, tests can and probably will affect each other. If you make a post test and then a delete test for a non existing item, the item from the post might show up and cause the test to fail when it shouldnt. That doesnt happen in sqlite

@alexandervasylevskyi1332 11 месяцев назад

Clever approach to a tricky task. For testing POST would you still have an in memory DB if you extracted work with DB to another class? Or you would Mock this dependency and Assert that specific action on this Mock was called?

@SyKot 11 месяцев назад

You’d still assert on the db. So full integration testing.

@gui.ferreira 11 месяцев назад

We can see the use of DbContext as an Interface to the DB. So, likely I put the DB Class under an Interface and then I would implement a Fake of that dependency. I want to have my tests extremely fast when practising TDD. Then, I can bring a small number of integration tests that make sure I can reach the DB correctly.

@alexandervasylevskyi1332 10 месяцев назад

@@gui.ferreira nice approach, I'm on your side here! You've definitely helped me build confidence in my TDD decisions!

@ilovepandaypoe6056 11 месяцев назад

how to deal with authorization?

@gui.ferreira 11 месяцев назад

Once you have it in place, there are many ways to do it through the WebApplicationFactory. Microsoft has some documentation here: learn.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-7.0#mock-authentication