The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function
(Robert C. Martin)
In the context of small teams and in order to facilitate change and adoption, I would recommend that TDD-like practices be implemented rather than attempting to implement a formal TDD process system; allowing for the a natural adoption of greater TDD practices at a later date. Vast volumes of text have been written on Test Driven Development and all of it should be read, but adoption and understanding takes time and part of the point is to make change in small, consumable, increments rather than large, overwhelming, ones. In this sense, it is better to take some small steps and alow them to grow over time.
In general, Developers should write tests as they develop code. This gives them a target to shoot for in their development, as well as integrating the regression test development into their process.
Rather than developing all of the tests right from the get-go, the first step would be to create a list of test stubs representing the list of features that are to be developed against. This list then becomes the development objectives for the development request.
//Sample Test Stub
/**
* <h1>New Feature requested by User</h1>
* <p>
* Complete description based on user requirements
* (see the "Process" section of this document)
* </p>
*/
@Test
public void NewFeature(){
Assert.fail("Not yet implemented");
}
This creates a list of tests that need to be fleshed out, and all fail. Now the developer has a clear list of unmet objectives that need to be fulfilled before closing the ticket. As the developer completes the tasks, they should fill in the tests to a point that they give a success signal. The task is not considered complete until all tests pass.
This mechanism of writing a list of objectives creates a rapid feedback mechanism. Since the developer is forced to think out the entire task prior to even investigating the problem, they are better able to focus their efforts at solving the problem.
True Test Driven Development (TDD) has strict forms that are to be adhered to, but these strict forms are a function of creating a theoretic framework. The theoretic framework is supposed to model a dynamic and agile environment. Here I am going to describe what I see as some best practices based on a foundation of TDD. I have yet to meet a team willing to undertake the discipline required for true TDD right out of the box, therefore this is TDDlite.
For a discussion of true TDD practices, I recommend Introduction to Test Driven Development by Scott Wambler.
