Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Becoming more Agile : I’m learning TDD

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:

  1. It isn’t particularly difficult
  2. I have a strong understanding of the domain (business)
  3. The client is cool

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.

[tags: Agile, TDD, .NET]

This entry was posted in TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

8 Responses to Becoming more Agile : I’m learning TDD

  1. karl says:

    Yves, I agree, but I still think it’d be tough to learn a significant new way to develop while trying to manage a complex project.

    I mean, TDD and unit testing isn’t something you get right the first time…some tests will be useless, some will cover too much ground…a lot won’t test the right thing or won’t do it properly…it’s a significant learning experience and in my mind getting the technique down is better achieved on simpler projects.

    TDD can help people learn the domain, but if your trying to learn TDD at the same time I think it’d get too much in the way.

  2. ” can’t imagine learning TDD on a difficult project with a hard to understand domain and a rigid client.”
    I think TDD is actually helping to understand a difficult domain. I know a lot of people using tests to learn a domain, I also know people that use tests to understand an existing API etc…

  3. byron says:

    theres no such thing as an ideal project. and if you wait for it, youll never learn tdd.

    thats what pet projects are for. Good luck with it all, glad you’ve finally seen the light!

  4. Kevin Dente says:

    Jim Newkirk’s book is also pretty good:

    It has good, real-world examples, not just the standard “TDD a stack class” stuff.

  5. Oscar Puga says:

    Yeah, there is no simple+complete+real examples of projects about TDD on the Net.

    Scott Bellware started a great series here some moths ago:

    Another promising project started at:

  6. hectore says:

    ey! I just want to say…THANK YOU!!! I was feeling kinda weird being one of those strange creatures that isn’t into TDD (yet!). And I completely agree with you, I’ve been meaning to catch up but all I see around the web are posts on the great advantages of TDD, a traffic lights metaphor and the write-make-fail-make-pass-refactor thing. Looking forward to the next entry on this. Keep up the good work.

  7. nuwanda says:

    I would recomend you a book i’ve read recently.
    It’s based on a small project done with TDD.

  8. Brian Button has an excellent series of posts spanning a couple of months that do a great job of showing a real case (albeit small) project done with TDD. You might check it out. The first post was in October 2004 (http://www.agileprogrammer.com/oneagilecoder/archive/2004/10/25/2805.aspx)