1

Many people so I read in google strive for unit-testing the repository classes with a so called in-memory database compared to integration tests with a real database.

Where is the problem of doing the latter?

Elisabeth
  • 20,496
  • 52
  • 200
  • 321
  • 1
    To the guy who gave me a -1. I have read the first time about this topic and did not find the supplied link so why then deserves this good question a punishment? – Elisabeth Feb 18 '13 at 10:23
  • Easily solved :) +1 since I agree, good question, even while it's a duplicate... – bas Feb 18 '13 at 19:29

2 Answers2

2

If you are using EF, you don't have to write tests to see whether EF persist data correctly or not. So you don't need a real database for the testing, all you need to test is your code logic and in-memory database is best suitable in this case, it helps to separate of concerns, flexible, easy to run and run faster than using a real database.

Furthermore, running integration tests with a real database is quite complex. It requires some configuration(connection string, drop and re-create database...) before running which may take time. The tests may fail because of mis-configuration(e.g. using shared database during testing) and it takes time to debug.

phnkha
  • 7,782
  • 2
  • 24
  • 31
0

Whether you are testing against an in memory database or real database you are not doing unit tests - both are integration tests. Both will actually test some form of connection and provider implementation.

The main benefits I would see of using an in memory database vs a real database are

  • Permissions - using a real database will usually require higher level of permissions and connectivity. Like file writing permissions or access to a database server. An in memory database may not require the same level of permissions.
  • Speed - it is quicker to spin up and tear down an in memory database than a real database

Depending on your pattern (i.e. if you're using a unit of work), it is likely that you don't even need a database to test your repositories.

Matt Whetton
  • 6,616
  • 5
  • 36
  • 57
  • yes I use the unit of work pattern. So I do not need a real or in-memory database. Please clarify that. – Elisabeth Feb 18 '13 at 09:08
  • You could abstract your DbContext and try to mock IQueryable as in http://stackoverflow.com/questions/13332002/how-to-mock-the-limitations-of-entityframeworks-implementation-of-iqueryable – Matt Whetton Feb 18 '13 at 10:00
  • But then I will just end up like in the link you posted me. Doing only Unit-Test is not enough the link says. Therefore I want to do at first integration tests thats enough for me. – Elisabeth Feb 18 '13 at 10:25