What are the London and Chicago schools of TDD?

Question

I’ve been hearing about the London style vs. Chicago style (sometimes called Detroit style) of Test Driven Development (TDD).

Workshop of Utah Extreme Programming User's Group:

Interaction-style TDD is also called mockist-style, or London-style after London's Extreme Tuesday club where it became popular. It is usually contrasted with Detroit-style or classic TDD which is more state-based.

Jason Gorman's workshop:

The workshop covers both the Chicago school of TDD (state-based behaviour testing and triangulation), and the London school, which focuses more on interaction testing, mocking and end-to-end TDD, with particular emphasis on Responsibility-Driven Design and the Tell, Don't Ask approach to OO recently re-popularized by Steve Freeman's and Nat Pryce's excellent Growing Object-Oriented Software Guided By Tests book.

The post Classic TDD or "London School"? by Jason Gorman was helpful, but his examples confused me, because he uses two different examples instead of one example with both approaches. What are the differences? When do you use each style?

Answer 1

Suppose you have class called "ledger" a method called "calculate" that uses a "Calculator" to do different types of calculations depending on the arguments passed to "calculate", for example "multiply(x, y)" or "subtract(x, y)".

Now, suppose you want to test what happens when you call ledger.calculate("5 * 7").

The London/Interaction school would have you assert whether Calculator.multiply(5,7) got called. The various mocking frameworks are useful for this, and it can be very useful if, for example, you don't have ownership of the "Calculator" object (suppose it is an external component or service that you cannot test directly, but you do know you have to call in a particular way).

The Chicago/State school would have you assert whether the result is 35. The jUnit/nUnit frameworks are generally geared towards doing this.

Both are valid and important tests.

Answer 2

The article Mocks Aren't Stubs, by Martin Fowler is a good introduction to the topic.

Depending on the design style you choose (and the design principles upon which you build your programs), there are at least two ways of seeing an object:

1. As a unit that performs computations based on inputs. As a result of this computation the object can return a value or change its state.
2. As an active element that communicates with other elements in the system by message passing.

In the first case, you are interested in what comes out of the processing or in which state the object is left after that processing. This is where methods such as assertEquals() enter the picture. In this case, it does not matter much what other objects were involved in the processing, which methods were called, etc. This kind of verification is called state-based verification and is the "classical" style.

In the second case, since most objects do not even return any result (e.g. void methods in Java), you are more interested in how the objects communicate with each other and if they pass the right messages under the circumstances imposed by the test. These interactions are usually verified with the aid of mock frameworks. This kind of verification is called behavior-based or interaction-based verification. One of its implications is the technique called Behavior Driven Development, by which you develop a class assuming that its collaborators already exist (even though they might not exist yet), so you can code against their interfaces.

Note that this is not an either/or choice. You can have a design style that mix both approaches to get the best out of each.