3 ms·
Fakes are great for objects that store data. Like in this example. If I use Entity Framework Core I also love the in-memory provider (or SQLite in-memory), wh
by andix 6y ago
Fakes are great for objects that store data. Like in this example.
If I use Entity Framework Core I also love the in-memory provider (or SQLite in-memory), which gives you a very well faked database context for unit tests.
In some cases you can create end to end tests, that run and verify the complete business logic, without hitting the database at all. A mixture between unit and integration tests.
https://docs.microsoft.com/en-us/ef/core/miscellaneous/testing/in-memory https://docs.microsoft.com/en-us/ef/core/miscellaneous/testi...
- zabil 6y ago> If I use Entity Framework Core I also love the in-memory provider (or SQLite in-memory), which gives you a very well faked database context for unit tests. This approach easy to setup, however I found that it slows down unit tests especially with data migrations and setup before each test (to discard test data from other tests). I've since limited these to test only migrations and in some well thought out integration testing.