This morning I presented an overview and example of Test
Driven Development to my office peers. I
had very little, if any time to prepare, so I completely ad-libbed it and used
a Development Driven Presentation TM approach with a simple Person class with
only one property.
I started with a brief summary of the concept, and using
NUnit and TestDriven.NET I proceeded to use tests to drive the development of
my sample class. I tested the
constructor and property get using comparison asserts, then tested property
validation by expecting an exception. I
added a data service class with a tested SavePerson method, and added a Save
method to Person to call the service. I
tested this using NMock to fake the data service and expect a SavePerson call.
Some questions arose from our discussion during and after
the session:
1.
I identified a need to increase knowledge on
programming with interfaces.
2.
We all have concerns about adopting TDD
‘mid-cycle' on a large and complex solution.
I suggested only testing changes and new code, and realised some sort of
discrimination would be required between code Before Tests and code After
Tests, possibly aided by a coverage analyser.
3.
One of us raised the issue of automating
repetitive tests, e.g. for high numbers of property methods on business
entities.
4.
Another expressed a lack of confidence in the
principle of only testing public types and members. He felt it would be risky not to test all
classes.
5.
We use Nettiers and Codesmith to generate our
DAL and business entity classes. It
looks possible to also generate tests for these, but this is outside the ambit
of TDD as the code generation is driven by a trusted third party
application. Customisations of generated
classes can however be test driven, and the generated tests may provide a
helpful starting point.
6.
TDD for our UI presents a huge challenge. It is a very complex, AJAX enabled, ASP.NET
front end. Automating it is not feasible
at the moment, unless someone knows of a shiny secret that is cheaper than
buying a house .
In all, I was impressed by the energy presenting this
subject generated in me. Despite being
dead tired, enough to fumble into some really gruesome copy and paste or typing
errors, I could have gone on for hours.
Two hours is very short for an ad-lib session. It was small audience, and while some were maybe
a little intimidated by some complexities, everyone is now keenly interested
and recognises the value of adopting the TDD approach.