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

THE FIRST TEST

Picking the first test to write for any feature is an important task. It sets the feature's direction and tone. It also ensures that the components and methods needed for the feature are built and layered in the correct order. The first test is usually for the most basic requirement of the feature you are building. As such, it indicates that as you continue development and move to refactoring, you never stray too far from the basics of the functionality that the feature needs to provide.

Choosing the First Test

In choosing the first test to write, you need to be sure that you really understand the user story and the business need behind it. The technological implementation will flow from the business need. In most cases a clear, logical progression determines how the features of each user story should be built. (Generally speaking, each application has a user interface layer of some sort on top of a business domain layer, with a persistence layer that communicates with a data store of some sort at the core. In some larger applications some of these layers are subdivided or use external resources, which can create some split or sublayering.

Regardless of how architecturally complex an application may be, I find it is generally easier to start by building features that are closest to the core of the application and then build out. This enables you to keep the core of the application as simple as possible. The layers built on top of this core have a simple set of APIs ...