Professional Enterprise .NET

Chapter 4. Test Driven Development

Wouldn't it be great if you had full confidence in the code you had written, you knew it worked, and you had only written the bare minimum of code to the meet the requirements? Test Driven Development (TDD) is all about addressing the needs of software development — writing something that works, something that meets a set of requirements, and something that is easy to maintain.

Despite the name, it may surprise you to learn that Test Driven Development is as much about the design of your software as it is about ensuring that your code is behaving and functioning in the way it was required to. The concept behind Test Driven Development is a simple one: write a test before you write any production code, watch the test fail, write just enough code to get the test to pass, then clean the code up and repeat. This has come to be known as the Red, Green, Refactor mantra (see Figure 4-1).

When you start with Test Driven Development, you write a test that fails; the test will fail because you haven't written the functionality in the production code. Most unit testing frameworks will display a red marker next to the test, indicating a failure, and this is where the "Red" comes from. After you have a failing test, you write the minimum amount of code to get it to pass and rerun the test. In most of the testing frameworks, a green marker will be displayed, indicating that the test is now satisfied; this is where the "Green" comes from. Last, you clean up the ...