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 behavior 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 BDUF.
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:
JUnit:
Refactoring:
4 Comments
Please visit my follow-up to Ron's message.
http://weblogs.asp.net/scottdockendorf/archive/2005/11/21/431100.aspx
For the article in question, .NET Developer's Journal - Dec 2004:
In there I stated that I made a mistake on my article in question, and should have never referred to it as TDD. There is no "official" interface-first implementation TDD and I should have corrected myself. I should have left TDD off the article and talked more about "auotmated unit testing."
The article that is authored by Scott Dockendorf and to which his comment refers is Unit Testing with Whidbey .
Microsoft have now removed their Guidelines for Test-Driven Development.
Microsoft has replaced Guidelines for Test-Driven Development with a new article that I think hits the mark. :)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/GuidelinesforTDD.asp