Testing with an in-memory database. Unit test or integration test?

Question

The concepts of unit test and integration test are well-defined: the former tests one component, the latter tests more than one component.

I use Effort to test my Entity Framework repositories. Effort is an in-memory database implementation, so we don't hit an actual database but just the memory so it's faster.

I'm testing solely my repositories by creating some fake data and populating an in-memory database with this fake data. I'm not mocking the data context. Should these be considered unit tests or integration tests?

Edit : I'm testing the methods of my repositories - eg CustomerRepository.GetAllCustomers. I'm populating this in-memory database with (say) 5 customers, calling the method, and asserting that I get those 5 customers back.

Answer 1

From your description of test for method CustomerRepository.GetAllCustomers , it does look to be a unit test since you are not using other services ( external or within your app ) .

If your method is simply using a db Connection object to retrieve rows from in - memory db instead of real db and no other public services being called or being mocked ( if called ) then you are doing a unit test ( which does seem the case to me even though you have not shared code of CustomerRepository.GetAllCustomers ) .

As already pointed out by a previous answer, just using in-memory db is not enough to tell if your tests are unit or integration esp. if you are testing DAO layer itself.

Answer 2

Using an in-memory database is not enough information to tell whether you are writing a unit test or integration test.

If you are only testing a small component like a method of a class then yes it's a unit test. But if that method calls other public methods to do it's job and you don't mock those dependencies, then that would be an integration test.