Test driven development sounds great, looks great, smells great, but is it really that useful for server applications? Unit testing means units of course but what happens when the unit is not a dumbed down component?
A short while back, I had a server rewrite and decided to implement contract first with NUnit. It didn’t take long to figure out (or remember that I’ve hit this before) that unit testing works through reflection on public classes and methods and isn’t very flexible for complicated cross-domain calls. The simpler scenario is a rich client executable using another assembly with a few hundred methods that need testing. You want to test these methods as the program is actually running but they are in classes that are either internal or private. Now to get NUnit to work, you must put everything public and implement testing from the client application. It seems like a messy, All-Or-Nothing situation. The assembly then gets remoted and you get no testing opportunities at all because the remote host isn’t setting up actual representative method calls.
Are there other tools that can actually unit test well without a recompile to change accessors to become public, and will operate regardless of the location or how many assembly layers are made? The alternative is my own testing framework with attributes, logging, and analysis.