I know. I'm late to the game, but I just finished reading TDD in Microsoft.NET. I figured since we were going to be using NUnit to do tests, what better book to read than one written by one of the creators of the tool we are using?

Anyway, I started reading it last Thursday, and finished up today at work. My laptop had to have it's screen replaced, so I had some downtime to finish it up. Here's the things I found valuable from the book:

1. It's a great primer on how to use NUnit, and tests in general.
2. It isn't a contrived example, as most examples seem to be - the first Stack example is, but the media example can really be applied to real world situations.
3. Fit. I've never used it before. I've heard of it, but didn't understand what it did. I would like to play with that some more.
4. Refactoring. I'd not really thought of refactoring the unit tests. And there are good examples of refactoring in general.
5. Database testing. This was probably the single most valuable thing I got from the book. I have always been unsure of how to test items that rely on database values. The book gives you some good ideas on how to handle this.

The book was thought provoking for me. I'm still not sure I'm going to be going "full fledge" into TDD - i.e., write a test, fix the failure, write another test, fix the failure, refactor, repeat. I can, however, see me writing tests once a structure is in place - the API is laid out for me, but not filled in. Non-compiling code bugs me, and writing a test first that uses non existent objects will cause the build to fail. I guess this is better than nothing.

I've never seen it mentioned, but has anyone used unit tests as a way for a lead developer to spec out code for other developers on the team? For example, let's say I am a lead developer, and I need a developer to create a class that handles a stack. I could write a bunch of tests that demonstrate the functionality, as well as a stub of the stack implementation, and the developer could flush out the stack class, knowing they are done when all tests pass. I know it goes against the "test, fix, test, fix, refactor, repeat" idea, but not too much. It's still TDD.

I'm also interested in UI testing. I've downloaded NUnitASP, and will test that out. I tried it once before, and thought about it for Tourney Logic, but found some shortcomings with testing custom server controls. Now that I'm working on a project with no custom server controls, maybe things will go better this time around.

I'm currently working on some database tests, and will post about my experiences with that. So far, I have one function running against a database, but it's a dev database - now we have to revisit the database build process!

NOTE: This post was written entirely after midnight, so if parts are incoherent, you know why!