Why separate out red tests from green tests? Because my green tests serve a fundamentally different purpose. They are there to act as a living specification, validating that the behaviors work as expected. Regardless of whether they are implemented in a unit testing framework or an acceptance testing framework, they are in essence acceptance tests because they’re based upon validating behaviors or acceptance criteria rather than implementation details.

Conversely, red tests are tests I write after the code is written to lock down some implementation.

Have you ever played the game 20 questions? Most of us have played that game at one point in our lives. One person thinks of something that could be an animal, vegetable, or mineral and then they answer yes/no questions that are asked of them. The point of the game is to ask as few questions as possible in order to accurately guess what the person is thinking.  This is how I think of the unit tests that I write the specified behavior as I’m doing test-first development. I ask what are the fewest tests that I need to write in order to assert the behavior I want to create.

I am a big advocate of having a complete test base and even erring on the side of caution when it comes to quality engineering and software validation but that is not what we’re talking about here. What we’re talking about here are the tests that we write when we’re doing test-first development and I’m proposing that writing those tests from the perspective of specifying the behaviors that we want to create is a highly valuable way of writing tests because it drives us to think at the right level of abstraction for creating behavioral tests and that allow us the freedom to refactor our code without breaking it.

In Double-loop TDD it’s functional testing that drives our development. We write a functional test for testing that our application satisfy some user stories. When the functional test fails we move to write unit and integration tests which in turn drive how we code our components.

The process of learning effective TDD is the process of learning how to build more modular applications.