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

5 ай бұрын

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

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

3 ай бұрын

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

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

8 ай бұрын

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

@gui.ferreira

7 ай бұрын

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

7 ай бұрын

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

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

5 ай бұрын

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

Ай бұрын

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

which ide-editor is that?

@gui.ferreira

7 ай бұрын

Hi! You can find it here: kzread.info/dash/bejne/qYV7wa6npMangbQ.htmlsi=RCA0v7disFsYEoSV

how to deal with authorization?

@gui.ferreira

7 ай бұрын

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

Hi, wich repo git? please

@gui.ferreira

2 ай бұрын

Hey! The "tdd" repo accessible on GitHub for Patrons.

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

7 ай бұрын

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.