Currently i am refactoring test for my context methods to not need a real database anymore. I use Ef Core.
So i read through the Microsoft documentation how to test context methods. I found the documentation for EF6 testing first and read the one for EfCore after.
Here are the links:
What i found interesting is that there are different best practices for EF6 and EF Core.
For EF6 Microsoft advises to use Mocking contexts with Moq or writing own test doubles. So both times mocking the context.
For EF Core Microsoft advises to use Sqlite or the built in InMemory database.
Mocking the context with Moq seems pretty reasonably for me. I just want to test the functionality of the methods. I have to do integration test anyways afterwards. Why is it not in the recommended ways for EF Core anymore? And more generally what are the advantages or problems with the different methods?
Take a closer look at the following quote from the same article...
SQLite in-memory mode allows you to write efficient tests against a provider that behaves like a relational database.
This provides you with constant and non changing test data but also the relational database problems and behaviors. It's much closer to the actual real life scenarios.
Mocking on the other hand provides you with an implementation where you can change the relational to any other model, thus it is much more versatile.
Since EF is for db and you are making tests for EF, then it makes perfect sense to go with the first option. More often than not you will not even need to test trivial operations like genetic repositories, e.t.c.
Make sure that when testing on a higher level (classes that consume repositories and such) you use mocking, as you want to mock interfaces which have no and should not have any coupling with the concrete implementations.