Post History

What are the cons of directly mocking Entity Framework DbSets instead of working with an in-memory database when unit testing the application?

I have recently contributed to a Clean Code project and had a discussion about [how to implement unit tests](https://github.com/jasontaylordev/CleanArchitecture/pull/251).

The project author argues for using an in-memory database (which easily replaces the real one) instead of mocking the DbSets and now I am doubting my own approach. 

The in-memory database approach for unit testing means that in order to unit test, the project setup is changed to use an in-memory provider instead of a real one (e.g. SQL Server provider). All services dependencies remain unchanged (no need for mocking here).

The DbSets mocking means that for each service I need to explicitly mock the dependency (DbSet<SomeType> is mocked using a library to a static list).

I tend to favor my approach because:

- sounds purely unit testing: mock the inputs, not an indirect input as the database
- no need for a special set up for testing (i.e. unit tests do not have to know anything about the infrastructure)

I am wondering what cons the DbSet mocking might have.