There are a lot of challanges to write unit-tests for database facing code. It typically requires a lot of setup code, a lot of effort to maintain, and hard to make it repeatable. It has seemed to be a universal excuse for a lot of teams to drop TDD practice.
So I gather here all various approaches that I am aware of when dealing with database unit-testing. In the next several posts, I will cover each of the implementations in detail, but let’s just have a quick overview on all the options. More than anything else, it’s just a matter of taste really, rather than situational. Hopefully after the next several posts you can make out the good and the bad of each approach.
- In-memory database using Sqlite
- Transaction rollback
- Restorable file-based DB
- Preset state with NDBUnit
- Fake DB provider with Linq
Throughout the major part of these posts, I will assume the use of nHibernate. Why? Simply because we need somewhere to work on. These approaches are however equally applicable to virtually any ORM or data-access framework.
PS: It is perfectly valid to argue that these are all integration tests, rather than unit-tests. But I digress.