TDD is not really a testing activity so much as it is about the creation of an executable specification. Because of this we value different things than testers might. Naming of tests, variables, and the use of well-named customized assertions are examples.
Test names are sometimes provided by the tools we use. Many IDE’s will allow you to submit a class or an interface to a function that will create an empty set of test methods for you, one per public method it finds. These tools are to be avoided in TDD, because we do not “test methods.” We specify behavior.
For example, if you had a class that represented a bank account which had a public method “GetValue()“, the suggested test would likely be “TestGetValue().”
In TDD, we would focus instead on the best way to describe this behaviorally. The fact that the method happens to be “GetValue()” is irrelevant; we would want the test to be named something more like:
…something which would be accurate whatever the specific syntax of the implementation happened to be. This seems trivial at first but becomes much more important when are hundreds of tests someone is trying to read five months from now in order to understand the system.
More to come…
This is Scott Bain. Visit us at www.netobjectives.com.