I am part-way through reading Test Driven Development in .NET by Jim Newkirk and Alexei Voronstov. Thus far I have had mixed feelings about it. The hardest parts about unit testing I have always thought are testing with a database, and testing UI, so I was particularly keen to see how they tacked the database access testing. The approach they use in the 5th chapeter is to create a single typed dataset to represent the entire database. They specify a select command and use a CommandBuilder to
automatically generate commands. Updates and deletes are performed using a DataAdapeter.Update() and DataAdapter.Delete() methods. I don't really think this is a real-world database access strategy since it
has a number of limitations. It is entirely possible to keep a similar approach but define your commands (either as text queries or as stored procedures). I don't think this would have not changed the testing approach (excepth perhaps writing a few more tests to test the command-building code) but the mere suggestion of testing application code and stored procedures in the same tests would probably have been too much for unit testing purists. The authors make sure they get themselves out of that little problem by refering to their tests as “programmer tests” as opposed to “unit tests“. In general I would have liked to possibly see a few different database access styles demonstrated, with testing strategies presented for each one, also possibly including the use of mock objects in database testing. I realize that this would probably have made the book considerably larger. Perhaps a seperate volume on the topic of testing database code is warranted? The
review and summary by Steve is pretty on the money, so read that if you're thinking about getting this one.
Update: source code from the book