The Spec
The Language
The Practice
The Books

Before Testing

One of the things that I like least is that feeling of aimlessness I sometimes feel when trying to solve a programming problem.  That's probably one of the the biggest reasons why I am attracted to the Test-Driven Development practice.  It encourages you to think about where you are going before you start going there.  I have found that even though TDD helps me define clear program goals, it does always help me get a clear vision of what I plan to build.

Without preparation, I can find myself writing a test, only to stop, comment it out, and create another.  Sometimes I stop that one too and create yet another.  Other times I will create a test, only to delete it a few minutes later.  This may not always be avoidable, but other times I was able to solve a rather difficult problems using TDD without much stopping. 

One of the important practices of the eXtreme Programming ecosystem is the "Planning Game".  This is the recommended pre-requisite to TDD and one that I recommend.  It is an attempt to take the requests for software and form them into small and obvious enough pieces that they can be estimated by the programmer and prioritized by the requester.  Programming requests are written into "Stories" and placed on index cards.  I have a specific suggestion for the writing of Stories which I plan to write in a different article.  They are written program features.  They are not a list of programmer tasks; they must be program features.  These Stories are very important.  I am assuming that you make these before you start programming.  If you don't I highly suggest that you at least write down a list of the program features you plan to make.  There are a couple of other things that I have found to be very helpful in getting my mental picture of the solution.

When I feel that I'm not sure where to start, I am learning to find a white-board and start defining the objects objects I plan to make.  I define the object methods and properties as well if I can.  I try to show which objects must use other objects.  I do this until I get a clear mental picture of a solution that I can work toward.  This picture gives me some hope and confidence that a soultion exists that I can actually do.  I find it is especially helpful to do this with another programmer present.  I actually think that pair-modeling on a white board may be often more productive than pair-programming (although I highly recommend both).

There is one other very important practice.  It is the eXreme Programming practice of "Spiking".  This is where you try programming something just to see how it works.  It is exploratory in nature.  This is usually done without TDD.  I am finding that this is so important that we need to do this as much as we can in order to learn how the software that we rely on really works.  You can write these exploratory code fragments into your testing framework and keep them as examples.  If you can't do sooner, you should at least practice this when you are trying to do estimates for Stories.  This need to make accurate estimates pushes you to really explore.  You should also do exploratory test writing as well, because sometimes it's the test that's the difficult thing to write.  New TDD'ers may be tempted to deliver a spike as finished code "because it works".  I have found that you will probably not do that much in practice.  When you do TDD you begin to rely on the comfort and security of your tested code.  You will probably find that your new-found ease afforded by tested code, is quickly destroyed by deploying untested code into production and get's more bothersome the more you make.  You will find that this produces a small but increasing amount unnecessary discomfort that guides you back to TDD.

There are many more excellent tools and skills that can be employed to uncover programming solutions and produce a strong mental picture of the solution.  These can include all forms of requirements, software, and database modeling.  There special kinds of meetings you can hold with software requesters that can help you work with them to clearify what they want.  There are also testing practices that help you make tests with software requesters that can go farther than anything I have seen to make your goals clear from their perspective.  Whatever it takes, it is important to use these things to help secure your mental model of the system you are trying to make in order to have an effective practice of Test-Driven Development.

Troy Taft is the Principal Consultant and founder of Troy Taft Consulting, a firm specializing in high value software development. He also authors a free monthly newsletter called Software Matters.

Copyright 2007 Troy Taft All rights reserved, you may print this article for your personal use.