Why Did I Go Agile? Part Two: TDD

As I mentioned in the first post in this series, Part One: An Open Mind, I was ready for change and willing to try TDD.

I had just joined the team that was forming to deliver a large project in a short timeframe.  I was responsible for an entire subsystem for a project that was supposed to ship in a few months.  At this point, I had heard and read a little bit about test driven development, and I knew two colleagues that used TDD successfully.  After the pains I had gone through on recent projects, I decided to try TDD out on my code.  I was used to doing unit testing after I coded, but doing it in a half-assed way, as there was never enough time to do it right.  So I read a few books, got a little bit of help, and started doing TDD on this subsystem.  It was tough at first, and I broke the rules a lot, but I was trying. In the end, I did not follow the rules completely, but I did have automated unit tests for most of the code (most of the tests were written before system code, but not all).  I delivered my code on our "code complete" milestone, even though I did need to work a few long days.  The test team took an initial look, and found a few environmental and configuration issues.  After ironing these problems out, which took a week, I waited for my testers to start filing bugs. 

And I waited…
…and waited…

Finally, after a week and a half of waiting, I stopped by the office of the lead tester, and asked if he had looked at my code yet.  He had.  He had a whole suite of automated functional tests and a number of manual and exploratory tests.  But he had found only one issue: the spec was out of date and needed to be updated.  I asked him to continue hammering on the sub-system and let me know if there were any problems. 

I took the opportunity to relax a bit.  After a week, I was caught up on documentation, my booklist, and I was bored.  So I asked my manager who was having problems and who needed some help because of their bug counts.  I was able to work on a few other subsystems and provide help for a few developers.  This became another death-march project for the other developers, with the team using me as a firefighter.  I was still waiting for a bug in my subsystem when we shipped, and am still waiting now, almost two years later. 

This experience completely sold me on TDD. It also set me up to be more open to other "crazy" ideas around agile.

Comments (6)
  1. john palmer says:

    I’m starting to look into TDD.  We are not an agile shop, but this looked (to me) as a technique I could personally use without bothering anyone (like management or QA).  I’ve messed with NUnit and now am messing with testing in VS 2005.

    The only reseach I’ve done is general web searches.  You mention that you "read a few books".  Do you have any suggestions, recoommendations along the TDD path?

  2. mpuleio says:

    John, I’d like to answer your question about which books I read. There are a number of books out there, some language specific, others more general. While I am going to list a few books here, keep in mind that this is not an endorsement by Microsoft, just a few books I found useful.

    The ones I read include:

    • Test-Driven Development in Microsoft .NET by Newkirk and Vorontsov.
    • Pragmatic Unit Testing in C# with NUnit by Hunt and Thomas
    • Extreme Programming Explained: Embrace Change 2nd edition by Beck and Andres
    • Extreme Programming Pocket Guide by chromatic

    I have also heard good things about Test Driven Development: By Example by Beck.

    I hope that helps.  Of course, grab a book, get the ideas in your mind, then try it out.  That is the best way to learn a lot of these skills: Doing them.

    [EDIT: Fixed formatting that was treated as text.  Added another comment]

  3. Michael Puleio, one of the people from MS PAT team, we have to thank for Web Client Software Factory

  4. Michael Puleio, one of the people from MS PAT team, we have to thank for Web Client Software Factory

Comments are closed.

Skip to main content