Unlike many of my CodeBetter colleagues, I'm not the most Agile
developer in the shed. Specifically, I've never done TDD for a real
system. I'm more of a unit-test-after kinda guy, which often (not
always) translates to unit-test-never. When surrounded by advocates, it
can be intimidating for an ignoramus to speak up. Luckily, on the same
day
David
reviewed "Applying Domain-Driven Design and Patterns : With Examples in
C# and .NET" by Jimmy Nilsson, I started working on a project ideally
suited for TDD. (On a side note, I plan on giving the book a detailed
review once I'm done.)
Rather than quietly learning TDD, I
thought it better to share my experience in the hopes of helping
others. TDD might be popular here at CodeBetter, but that's the
exception to the rule in the .NET community.
If you are
totally new to domain driven design (ie, maybe you use DataSets a
lot..ya ya, they aren't mutually exclusive, leave me alone) , have no
exposure to unit testing and don't know anything about the open-source
trio (nUnit, nAnt, CruiseControl.NET) you have a huge job ahead of you.
Personally, I'd recommend you familiarize yourself with domain driven
design on a number of small sample projects – writing code that
manually maps between your domain and data model. Hopefully there's
someone in your team that can help you out.
The very first piece
of advice I'd give to anyone wanting to learn TDD is to wait for the
right project. I called my project "ideally suited for TDD" for three
main reasons:
- It isn't particularly difficult
- I have a strong understanding of the domain (business)
- The client is cool
I
can't imagine learning TDD on a difficult project with a hard to
understand domain and a rigid client. Specifically, I think having a
strong understand of the domain has really helped out – it's a huge
load of my learning curve.
So far, I've found very little
quality material on the web that'll help you out (maybe I'm looking at
the wrong place?!). Most tutorials simply spit out text book material.
They'll have the image that shows the typical TDD flow (write the test
.. make it build .. make it fail .. make it pass .. refactor). Come on,
give me some concrete examples! Jimmy's book actually provides you with
those real examples, but it'd still be nice to be able to draw from a
greater collection of samples. I'm blown away that there isn't a simple
TDD example of testing a User class somewhere on the web (I understand
that it isn't' that straightforward because you'll quickly hit the
persistence layer).
Another great piece of advice is to keep
things simple. I've always been a huge proponent of YAGNI (you aren't
going to need it) and I find that while trying to make a test pass, the
simplest solution is almost always best – even if I know it won't be
the final solution. I've always programmed like this, but the
granularity of unit tests and the instant feedback from TDD makes it
very natural to achieve.
Over the next couple weeks, I'll be
posting some material squarely aimed at TDD newbies like myself.
Hopefully the experts will correct any mistakes I make – I'm certainly
not afraid of making mistakes when learning something new. I've created
a new category (look to your left) called TDD for this material.
Oh, and in case you haven't figured it out. I strongly recommend you buy "
Applying Domain-Driven Design and Patterns : With Examples in C# and .NET"
by Jimmy Nilsson. In no way am I affiliated in any way with this book.
Again, I do hope on giving a detailed review in the near-ish future.
Technorati Tags: Agile, TDD, .NET
Posted
Wed, Jun 21 2006 12:51 PM
by
karl