How not to do it: Test-Driven Development, Microsoft-style

In their Guidelines for Test-Driven Development, Microsoft says "If your software-development project uses test-driven development, you can benefit from features of Visual Studio 2005, and in particular, features of Visual Studio 2005 Team System. These features include the unit test type of Team Edition for Testers, and especially the ability to generate unit tests automatically; automatic refactoring capabilities that are introduced in Visual Studio 2005, and the Class Designer tool. The unit test support of Team Edition for Testers is particularly suited to TDD because these Team System testing tools can generate tests from a minimum of production code."

Read the guidelines and then erase them from your memory.

TDD is all about RED GREEN REFACTOR - write some unit test code that fails, then write the simplest code to make the unit test pass, then refactor the code to remove code smells and check that all unit tests still pass.

With experience a developer can complete an iteration of the test-code-refactor cycle in minutes to give the impression of concurrent coding and testing, a bit like a CPU switching rapidly between processes to give the appearance of concurrent execution. Taking the metaphor a step further, as a preemptive scheduler triggers a context switch between processes, a green bar, indicating that all unit tests have passed, initiates a new iteration of the cycle. The conscious act of writing tests first to capture the desired behaviour of a class, coupled with merciless refactoring, enables the design to evolve in baby steps. This is defeated when you generate the unit tests from skeletal code; you're back to DUF.

If you do not adhere to the test-code-refactor cycle you lose inherent benefits of TDD. Unit tests that are run at the same stage of the cycle, in every iteration, and pass with a green bar give a developer the confidence to proceed and make changes. When a red bar occurs, a developer fixes the problem before proceeding, confirming the fix with a re-run of the unit tests. Locating the problem is easily accomplished because only a small number of lines of code are added per iteration of the cycle.

Here's some good reading material on TDD, JUnit and refactoring.

Test-Driven Development:
Test Driven Development by Kent Beck
Test Driven Development: A Practical Guide by Dave Astels
Agile Java: Crafting Code with Test-Driven Development by Jeff Langr

JUnit:
Test Infected: Programmers Love Writing Tests
JUnit Cookbook by Kent Beck, Erich Gamma
JUnit in Action by Vincent Massol
JUnit Recipes: Practical Methods for Programmer Testing by J B. Rainsberger

Refactoring:
Refactoring: Improving the Design of Existing Code by Martin Fowler
Refactoring Workbook by William C. Wake
Refactoring to Patterns by Joshua Kerievsky

To keep up with the latest news and developments in the field of TDD visit:



PLEASE NOTE: In a previous edition of this post I incorrectly attributed Guidelines for Test-Driven Development to Scott Dockendorf. Scott has rightly pointed out to me that he is not the author of any part of this MSDN document, nor is he responsible for its content.


Tags: agile, tdd

posted by Simon Baker @ permalink
blinklist : del.icio.us : digg : furl : simpy : spurl : reddit