Although your blog is specific to Entity Framework, I think it is worth looking at other Solutions and seeing how these could be adapted to Entity Framework or how Entity Framework could be adapted to make testing without actually hitting the DB simpler.

We all accept that as part of your test pack there are going to be integration tests and Acceptance tests that actually hit the Database.

In my experience there are a whole range of tests (Call them integration tests if you want) that need to persist some objects and load them again. Projects with complex processing logic etc.

In all these cases you either need a database or you need to be able to Fake a data access layer.

If you are using a framework such as Habanero or NHibernate this should be relatively simple since these pretty much ensure that database differences are accounted for.

Habanero uses an InMemoryDatabase which is a Fake it behaves exactly like a real database as far as Habanero is concerns and implements all the same constraints etc.

I have used this on my last few projects and found it to be incredibly simple, usable and resulted in incredibly fast tests with no test interactions etc. It worked so well that when I touch an old project I automatically change to using the InMemory
The In Memory Database just stores the objects. You don’t need to propogate schema changes to it etc etc.

It was obviously a bit of work to create but the Habanero guys have already done it.

The unintended benefits of using the In Memory database for Agile developement is that we have found that we are doing large chunks of development using just Business Objects and the In Memory database (No adding removing columns/Table etc from the Database). Even the visual testing by the developer is done using an In Memory Database. When you go into stabilisation i.e. testing by testers before deployment we generate the DB Schema and run our Database integration and acceptance tests and then do visual testing.

Sorry for the long reply but I have found this feature incredibly usefull and very supportive of Agile development and I would like to see it incorporated into other frameworks.

Shanti Dev

The number of gotchas in Linq-to-sql is definitely becoming mind-numbing.

public void DiscardInsertsAndDeletes(DataContext data)
{
var changes = data.GetChangeSet();

foreach (var insertion in changes.Inserts)
{
data.GetTable(insertion.GetType()).DeleteOnSubmit(insertion);
}

foreach (var deletion in changes.Deletes)
{
data.GetTable(deletion.GetType()).InsertOnSubmit(deletion);
}
}

Marcus: I’m glad to see that is working well. The only thing I would be worried about is that NHibernate may behave differently with each DBMS in some cases. However, it the behaviour is consistent then that is probably a great solution.