A beginners explanation of the Chicago & London approaches

Author clarification: It has since been revealed to me that the Chicago school of thought is actually called the Detroit school. Please use this term for any future references.

I recently received feedback from a code review that my TDD approach may benefit from using the London school of thought approach vs. the Chicago school of thought approach. And my initial reaction was one of confusion...

There are different methods to approaching TDD tests? And what are the Chicago and London school approaches?

So, I decided to research these approaches over the weekend and share what I understood in case it is helpful for anyone out there.

Let’s start with the Chicago approach.

Chicago School of Thought TDD (Inside Out/Bottom Up/Classic)

This approach starts at the unit testing level and allows the developer to focus on one thing at a time. In particular, it focuses on filling in the detail for a particular feature, before moving onto the next.

An example of this approach came to mind when I was building a bowling scorecard program a couple weeks back.

I approached this project by testing and building a 'Game' class that focused on keeping track of the game (i.e. the frame and rolls a player was on, the game ending etc...) and then I moved onto testing and building the 'Scorecard' class that would calculate the score.

After all the unit testing was done, I moved onto feature testing and building the front-end interface where this information would be displayed to the player and ultimately where the player would play the game.

This is a Chicago approach to building the program as:

• It focuses on building the program from the component/class level level upwards.
• It focuses on state based testing, seeing through the testing of one class and its behaviour at a time.

London School of Thought TDD (Outside In /Top Down/ Mockist)

You might have guessed this but the London School of Thought is essentially the opposite of the Chicago approach.

This approach starts at the outer, feature layer of the program and slowly moves into testing the centre layer of the program (i.e. the unit tests for the components).

So rethinking my approach to the bowling scorecard program, I would start with feature tests, planning how the interface would look to the user and how the user would interact with it before moving onto the unit tests.

And admittedly, this is a little weird to me. Why would you start implementing feature tests without having any of the components you would need to create it (i.e. the game and scorecard objects)?

Well this is where mocking comes in which is a more crucial part of the London based approach (but still can be used in both!).

Let’s say my page would display the frame and roll the player was on, as well as the current score. In order to test that this information is displayed, I would need to mock the classes and return some test data that I would feature test is displayed on the web page.

For example, let’s say the page starts with a frame of 1, roll of 1 and score of 0. The player then rolls a 5 and I would want my web page to display that they are on their next roll with a score of 5. (i.e. Frame: 1, Roll: 2, Score: 5). And this is what I would feature test using mocks and stubs to return the fake data in place of the real data that I would receive had I implemented the classes and methods beforehand.

Once that feature test is done, I can unit test scorecard and game classes to replace those mocks and return real data.

The London School approach:

• focuses on building the program from the outside, feature level moving into the inner level.
• leaves the actual implementation of the classes until last

Ending remarks

I hope this article was useful to get an introduction to Chicago and London approaches to TDD. There is a lot that I haven’t mentioned here to keep it as simple as possible (and also as I'm still learning about the approaches), but I will leave some resources that I found useful along the way if you are interested in learning more:

• https://8thlight.com/blog/georgina-mcfadyen/2016/06/27/inside-out-tdd-vs-outside-in.html

• https://medium.com/@adrianbooth/test-driven-development-wars-detroit-vs-london-classicist-vs-mockist-9956c78ae95f

• https://softwareengineering.stackexchange.com/questions/166409/tdd-outside-in-vs-inside-out