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.
Prior to adopting CoolStorage.NET we always implemented the repository pattern in some form. My team and I were never really happy with this pattern however as noone wanted to invest the time to write our own custom query system (we’re a .NET 2.0 shop still so LINQ isn’t a real option yet).
Finally, after moving to CoolStorage.NET for ORM, we were left with the ActiveRecord pattern… Now what? Write repositories that wrap around ActiveRecord objects that are mapped to non-active record objects?!
There are lots of options and patterns one could use, but ultimately we decided that the goal was to be able to test our domain objects (including the mappings) and not write even more code. As such we went with the In-Memory DB solution. After 4 weeks with this solution I must say it works really well. In fact, the tests end up revealing far more about our implementations and its “rightness” then I thought it would.
Just a word of note: we used VistaDB for our in-memory tests…
In the end we must leave aside semantics and just make things work. I don’t really care if the test is “Integration” or “Unit”, only that it runs pretty fast and actually tests what I need it to test.
I look forward to reading your coverage of these methods.
Comment by Lucas Goodwin — October 2, 2008 @ 12:30 am |
[...] @ 11:19 am Tags: ORM, Test Driven Development I have mentioned briefly in previous post about 5 different approaches to write unit-test for data-access code. So now I will try to cover the first method in more detail. And among the 5, this method seems to [...]
Pingback by Data Access Test with Sqlite « Hendry Luk — Sheep in Fence — October 7, 2008 @ 11:19 am |
[...] what can we do to solve this problem? Well, head over to Hendry Luk’s blog, where he gives a comprehensive overview of all our options, which [...]
Pingback by The Smart Way To Test Your Data Access Code « OpenLandscape — October 11, 2008 @ 10:16 pm |