Geeks With Blogs
Blake Caraway
I'm currently working on a smart client project at work. For the past year I've been learning about Agile software development, especially the topic and practice of Test Driven Development. This smart client project is my first real chance to put many of these newfangled ideas into action.

Seek The Green
On this project we are using the MVP pattern for the client-side development out of a desire to make the main application logic as testable as possible. With this in mind I started out my feature development trying to write targeted, intention-revealing unit tests while keeping in mind the qualities of good unit tests. As per Michael Feathers, unit tests should run fast and help localize problems. After coding a couple features on this project in test-first fashion, I can honestly say that I've become quite comfortable with the whole red-green-refactor paradigm in a very short period of time. In fact, I've begun to _live_ for an 'all green screen' when running my tests in NUnit-GUI (or when using TestDriven.Net, looking for the '0 tests failed' indicator in the Visual Studio status bar). It's very satisfying to see the test suite and code base build-up rapidly using this process.

Revelations
The two coolest things about TDD that I've seen thus far is 1) the high quality of the code that comes from following the process and 2) the way code is documented by the unit tests that cover it. I've been out of the office the past week for the birth of our second child, Grant. To help remember where I left off in my coding tasks, I was able to use the unit tests to see the work I'd accomplished (documentation). Not only that, at any given moment, to find out what my code is doing, I can take a quick look at my growing suite of unit tests (intention-revealing). The tests almost read like an outline to a short story. One other note about unit tests serving as documentation...when Microsoft released its Composite UI Application Block (CAB) back in December, I pulled down the source code and sample projects. I tried looking into the code and immediately noticed this was a very large framework for building complex smart client applications and really didn't know where to start. I noticed there both Team System and NUnit test projects included in the download, so I was able to start there and get a better idea about all the 'moving parts' of the system. I kept this in mind as I began writing my own unit tests. Although, I must say, my resulting unit tests seem to be better at revealing the intention of the code than those test fixtures provided with Microsoft's CAB.

Schedule Trumps Process...and Quality
Given the typically aggressive project schedule we usually work with (against?), the other developers on this project never really tried writing tests first to guide their work, despite us spending a not-so-modest amount of time the first week of development in large-scale XP sessions (about 5 of us in a room following along using a laptop/projector combo and rotating drivers) where we as a development team stepped through a couple use cases and began writing production code in a test-first manner (the subject of introducing a team to the practice of TDD - and the challenges involved - will be covered in a future post). Instead, they dove right in writing code as usual. Many times over the past few weeks I've attempted to look at the features the other developers have been working on, but have found that the absence of unit tests makes this task very difficult. I mean, I know the general plot of a particular feature, but to see how the code is working I have to follow method after method thru the code and maybe even debug to get a solid understanding.

No Going Back
Developing code 'the old way' - i.e. creating legacy code with every keystroke that doesn't lead to a good unit test - seems so very wrong all of a sudden. I feel like I'm more focused when designing/coding test-first. There's less of a chance of 'going off the reservation' and allowing myself to digress and write code for other features as the solutions pop into my head before fully completing the task at hand. TDD keeps me more honest and that's a good thing.

That's enough for now. Hopefully this will help offer encouragement for anyone looking to break into TDD. I know I was somewhat skeptical when I first tried writing code in a test first manner. I'm obviously still learning, but now that I have seen the process and how quickly it proves its worth (I'll discuss this more in a future post, as well), I've seen the light. Those individuals that remain skeptical of TDD - and Agile software development in general - call this shift in thinking 'drinking the KoolAid' - at least the developers/managers I work with on a daily basis do. It's a not-so-subtle reference to buying in wholesale to a movement or new way of thinking and more or less becoming a zealot to a cause on faith alone. I have more thoughts on why developers/managers react in this way, but yep, you guessed it...I'll save it for another post. Call it whatever you want. If I'm 'drinking the KoolAid', then I guess my preferred color of said sugary beverage is NUnit Green. Posted on Wednesday, February 22, 2006 8:16 AM TDD | Back to top


Comments on this post: Mine Eyes Have Seen The Glory...of TDD

# re: Mine Eyes Have Seen The Glory...of TDD
Requesting Gravatar...
Great to see you blogging, Blake.
I look forward to hearing more of your agile adventures in a not-so-agile-friendly environment. Keep fighting the good fight!

(And congratulations on the newborn! I added a son this past week too)
Left by Joshua Flanagan on Feb 22, 2006 12:46 PM

# re: Mine Eyes Have Seen The Glory...of TDD
Requesting Gravatar...
Glad to see another Caraway blogging. I've got you in my blogroll now.
Left by Clint Caraway on Feb 22, 2006 1:12 PM

# re: Mine Eyes Have Seen The Glory...of TDD
Requesting Gravatar...
Looking forward to another post about TDD.
Left by Jeffrey Palermo on Mar 22, 2006 6:16 AM

Your comment:
 (will show your gravatar)


Copyright © Blake Caraway | Powered by: GeeksWithBlogs.net