Sorry folks, no code in this post. 

I just finished giving a one-hour presentation on how to do TDD with VS 2003
and NUnit.  I gave a brief overview of TDD but didn’t try to persuade them to
change right off the bat.  Heck, I’m just getting started!  I started with the
approach of referring them to the explanation given on AgileData.  Then I went into
a demonstration.  I emphasized the need to see the test fail to ensure that your
test is correct.  One time, I forgot to add an Assert to the test, and, of
course, it would never fail.  That hit home the point that seeing it fail
verifies that the test is good.

One of the concerns raised about using this methodology is:  “That’s a lot
more code to write”.  We talked as a group about the benefits of having unit
tests for all the code in a project.  The project could be shipped to another
building totally cut off from all networks, and another team could add
functionality and be sure they didn’t break anything else as long as all the
existing unit tests all continue to work.

Another question was if this approach would lead to better code. . .or “what
about the novice programmer”.  We talked about how this can lead to a clean
design but that it would not artificially make a bad programmer’s code better. 

I only started doing TDD last week, so if almost feels like I’m leading the
group while stumbling through the dark myself.  It’s becoming familiar quickly,
though.  I’m learning how to decouple external dependencies and test in
isolation, using SetUp and TearDown methods, etc.  Performance counters were a
bit tricky, though because I couldn’t decide if they should be considered an
external dependency that should be stubbed or not.  After all, I’m just calling
classes in the .Net Framework.  The code isn’t calling over the network.  With a
database, it’s clear:  stub it! 

Another topic that came up concerned some of our existing codebase.  We have
some class libraries that were designed to be consumed in a flexible manner, but
not test-first, and we don’t have unit tests for them.  Each of the classes has
about 5 overloaded constructors.  We discussed that if we developed it with TDD,
we’d only have the constructors that were required or that we tested.  We may
still decide that we want 5 constructors, but each one would have to have a
consuming test written first, and I would think all other tests on that class
would need to be performed with an object constructed with each of the
constructors.

The more I learn about TDD, the more I find I need to learn.  What a vicious
cycle!  I’m loving it, though.