There are 2 schools of thought in the TDD space: top down and bottom up, the former becoming increasingly popular, while the latter it’s the classical approach used to teach.

Given that a developer is working on an Object Oriented paradigm, if he chooses the bottom up approach he’ll start writing unit tests for the objects he needs to complete the requested feature. The catch here it’s finding which objects are these. This may lead to some refactoring and experimentation until the right set is defined.

Top down approach

A response to the problems above it’s to start writing tests at a higher level of abstraction. So now instead of defining the object interface we start by designing the component interface or even the complete application API. This gives context and help define how the objects are gonna communicate and which messages they should understand.

BDD

BDD it’s a style to help the developer to understand that he is designing not testing and provides a concise language that both, the business and the development team can use. It’s called Gherkin and has several artifacts. The following example shows the format.

1: Feature: Some terse yet descriptive text of what is desired

2:   Textual description of the business value of this feature

3:   Business rules that govern the scope of the feature

4:   Any additional information that will make the feature easier to understand

5:

6:   Scenario: Some determinable business situation

7:     Given some precondition

8:       And some other precondition

9:     When some action by the actor

10:       And some other action

11:       And yet another action

12:     Then some testable outcome is achieved

13:       And something else we can check happens too

14:

15:   Scenario: A different situation

16:       ...

A concrete example:

Feature: Serve coffee

Coffee should not be served until paid for

Coffee should not be served until the button has been pressed

If there is no coffee left, then money should be refunded

 

Scenario: Buy last coffee

Given there are 1 coffees left in the machine

And I have deposited 1$

When I press the coffee button

Then I should be served a coffee

These Gherkin file it’s parsed and some code templates generated from it. This code templates are the placeholders for the testing framework and the start point for the developer to begin coding.

Just enough design

Another approach to work around the limitations of the bottom up approach is to do just enough up front design typically using UML sketches. This allows the development team to brainstorm different designs in front of a whiteboard. The purpose of these designs is to identify the early players of a use case. The implementation is then left to the TDD practice. Common tools are UML’s use case, activity and interaction diagram. I have described this approach before.

 

A few words on the practice of TDD

Whether you choose a top or bottom approach the important thing to keep in mind is that you are not writing tests, you are specifying the way you want the code to be used, even before that code exist. This is more of an experiment than a testing exercise. The idea is to find the abstractions and messages needed to resolve the problem at hand without getting distracted by implementation details such as DB, UI or web services.