Professional Test-Driven Development with C#: Developing Real World Applications with TDD

IT STARTS WITH THE TEST

The first D in TDD stands for “driven.” This means that in your practice of TDD, you must let the tests drive your development. This seems like a simple enough concept. However, when developers who are new to TDD start trying to work in a test-driven manner, they tend to fall back into their old, comfortable routines.

Most traditional development work flows start with requirements gathering. The business managers sit down, usually with a project manager and an architect, and sketch the broad strokes of a system. This process goes through several iterations in which the design is refined and details are expanded. Finally, a set of specifications for either a new application or a change to an existing one is produced.

For development teams or developers who don't practice TDD, the next step is to write the code. As a developer, you use specifications derived from the business requirements to define entities, service classes, and application work flows. At this point the system's quality depends on the developer's understanding of the technical specifications and business requirements as written. When you are done (or you have reached a point that represents your concept of “done”), you send the application to QA for testing. Invariably, QA finds defects in the feature.

Now it becomes your job to correct the defects. Without unit tests to help locate and diagnose the defect, most developers turn to the debugger, placing breakpoints in code where they think ...