I’ve been a big fan of test-driven development (and unit testing) since I first learned about it a few years ago. It wasn’t until this month that I learned about NDbUnit. This little library is a great value-add for unit tests that involve databases. The creation of test data is tedious if done manually (NDbUnit uses XML for data files), but that’s the only real drawback I’ve found so far in my limited experience with it. It plays very nicely with NUnit, MbUnit, and TestDriven.NET.
You can get binaries and source code for NDbUnit from Quality Labs. I also put together a (very) small sample project with Visual Studio 2005 that you can try out.
Will have to check this out. What I try to do with my Gentle generated unit tests (which are currently half-baked and really not very useful – so I’ve pretty much stopped using them until I can revisit the code generation) is to make “mock” objects that are created and used in the unit tests. The code generator basically makes random data to pump into the mock object that is then used.
A couple of problems with this are that a) your mock data is only generated once, when you first generate the code for your object – which might cause tests to fail if the objects aren’t cleaned up properly, and b) your test users end up with names like MJKIOPSNFUZDRGFASF, which isn’t very useful.
I’m considering that when I sit down to flesh out and rewrite the Gentle code generation library, to have a little Access DB, or text files that you can put some test info into. So, perhaps theres a table called “Names”, and the code generation recognizes certain column names as name fields and pulls the test data from there. Or “Addresses” or “Product Name” etc. I would probably also include a set of “bad data” with things like semicolons in them, quote marks, etc, so you can test those cases out too…
Too much to do! 🙂
You’ll probably find NDbUnit a huge help then. Using the DbOperationFlag.CleanInsert or DbOperationFlag.Refresh operations will let you reuse the same data or modify it at will.
Yea, DBUnit rocks, and not just for testing, it’s a good tool. There is an undocumented feature called a DBUnit “Consumer” which I have used successfully that allows you to process database entries “inline” using the SAX functionality. I’n not sure if the .NET version of DBUnit has this, but it is VERY handy for very large data sets.