Part II: Traffic Light Software System

Specification workshops, wishful thinking, and collaboration might serve you well in the beginning. But you can extend the ATDD approach even more. A multitude of teams have experimented with very different solutions to the problems they were facing after applying ATDD for a while. A collection of these solutions can be found in Specification by Example [Adz11].

Rather than showing a solution from one team here, I would like to challenge the constraints that some teams imposed on themselves while applying ATDD. The “driven” part of the name suggests that it is possible to drive the application code from the examples. With a combination of lessons I learned from test-driven development, and what I found myself doing at times, in this part I will pair up with you, dear reader, in order to work through a system using ATDD and TDD while the design of the domain code grows.

In this part we will take a look at a traffic light control system. We will evolve a system together over the course of the development. Similarly, we will evolve the tests together with the system. At times we will examine portions of the support code to gain insights into possible designs for the production code. The tests will be automated based on an API in Java using FitNesse with SLiM.

Since I plan to pair up with you, we will leave the narrative style I used in Part II. We will work through the examples together, but we should start with a specification workshop first. Since I am from Germany, and Germany has quite different traffic light rules compared to other countries in the world, we have to get to a common understanding of the application domain first. Let’s get started with this.