I have looked through most of the answers given regarding using in-memory database for unit test, but I could not find one that was clear to me.
I am writing some unit tests to cover some of our codebase. The codebase is written in ASP.NET Core and EF Core. I am using xUnit and Moq.
I have read and understood the concept of unit test vs integration tests.
As I understand, writing unit tests means testing a code in isolation from other dependencies and to achieve this, we can mock those dependencies so we can test the code only.
However, I found that it is a bit more work setting up mock of dependencies that I need especially if these dependencies are repository dependencies.
When I tried using an in-memory database, all I need to do was setup the in-memory database, seed the database, create a test fixture and it works. And in subsequent test, all I have to do is create the dependencies and it works just fine.
To mock the repository, I have to setup a mock and return value. And then there is the complexity of mocking an async repository as explained here: How to mock an async repository with Entity Framework Core. For each test, I have to mock the repository that is needed which means more work.
With all these in mind, would it be better if I just ditch mocking and use in-memory database? Also, would this not be seen as integration testing though it's an in-memory database.
I created two different tests using the in-memory database and mocking.. - The in-memory database tests understandably took more time, but the difference is usually about 1sec longer than the tests using mocks.