Testing with a database in memory. Unit test or integration test?

Question

The concepts of unit test and integration test clearly defined: the former checks one component, the latter tests more than one component.

I use Effort to test Entity Framework repositories. The effort is the implementation of the database in memory, so we do not encounter the actual database, but simply the memory, therefore it is faster.

I only test my repositories by creating some fake data and populating the database in memory with that fake data. I am not mocking the data context. Should they be considered unit tests or integration tests?

Change I am testing the methods of my repositories - for example. CustomerRepository.GetAllCustomers. I populate this database with (say) 5 clients in memory by calling a method and claim that I am returning these 5 clients.

Answer 1

From your test description for the CustomerRepository.GetAllCustomers method, it looks like a unit test since you are not using other services (external or inside your application) .

If your method just uses the db Connection object to retrieve strings from in-db memory instead of real db, and no other public services called or mocked (if called), you do a unit test (which seems random to me even if you don't separated code CustomerRepository.GetAllCustomers ).

As noted in the previous answer, just using in-memory db is not enough to determine if your tests are unit or esp integration. if you are testing the DAO layer yourself.

Answer 2

Using a database in memory is not enough to indicate whether you are writing a unit test or integration test.

If you are only testing a small component, such as a class method, then yes, this is unit test. But if this method calls other public methods to perform this task, and you are not mocking these dependencies, then this will be an integration test.