London vs Chicago

Originally published in:
https://chemaclass.es/blog/london-vs-chicago/

There are two known schools in TDD: the mockist school (aka Outside-in) and the classicist school (aka Inside-out).

Context

In TDD, there are two known schools: the mockist school (aka Outside-in) and the classicist school (aka Inside-out).

Why London and Chicago?

Two companies, one from London and another from Chicago, claimed to do TDD, but they were focused on different aspects. The London company was building software from outside-in, while the Chicago company from inside-out. Let’s see them in more detail.

Outside-in: London School

It provides a behavior-driven approach to TDD. Starting from the outside of the application and working in moving to lower layers. For example, starting from the API/Controllers down to the application or domain layers.

PROS

  • Behavioral Focused: this requires a lot of test doubles because you will test a lot of abstractions that don’t exist yet as you are creating a high level of logic first. You aren’t going to write dead-code but it will be easy to create tests highly coupled to the logic and therefore making refactoring a difficult task.
  • Command-Query separation: is a discipline for managing side effects. Either you perform an action (command) or you ask for a value (query).

CONS

  • Fragile Tests: it tends to create tests that break easily because they are usually too coupled to the production code.
  • Difficult Refactoring: for the same reason as “Fragile Tests”, having tests coupled to production code make continuous refactoring very difficult and time-consuming.

Inside-out: Chicago School

It’s an informal, exploratory, state-based approach of TDD. Starting from the inside of the application (usually the domain) and working out towards the APIs.

PROS

  • Strong Safety Net: it tends to produce tests that are decoupled from the implementation. Enabling you to adopt a more experimental style of changing software without fear of breaking it. This is desired for continuous refactoring.
  • High Cohesion: as tests become more general, the production code becomes more specific. This promotes high cohesion, and with high cohesion comes loose coupling. Something that promotes high code quality: extensibility, maintainability, and testability.
  • Minimizes Test Doubles: building from the inside out requires fewer test doubles since you are building on top of the previously written tests. This helps to develop less fragile tests.

CONS

  • YAGNI: it’s often over-engineering solutions, with code that is not really needed (or even used!) in the end.

Conclusion

It’s not about choosing one over the other. It’s about understanding your quality model and driving optimization towards those qualities that need to be optimized. London and Chicago each have their pros and cons. The best approach to TDD is an integrated adoption of these two schools.

References

--

--

--

Aka: Chema. I love writing about stuff that I find interesting and bring some value to my life, so I can share them with you. https://chemaclass.com

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Certificates issuance and renewal using certbot docker images with DNS challenges on BIND9 DNS…

How To Set Up A CSS Architecture For React Apps

ValueError: too many values to unpack (expected 2)

Continuous delivery of react app with Jenkins and Docker

Protocols in Application Layer

My experience with Crossover after 2 months

Introduction to Arrays in Python

The Benefits of Using StudioPress, Genesis & Their Themes for Your WordPress Site

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jose Maria Valera Reales

Jose Maria Valera Reales

Aka: Chema. I love writing about stuff that I find interesting and bring some value to my life, so I can share them with you. https://chemaclass.com

More from Medium

Software Estimation: A Two Dimensional Approach

How a code quality company dealt with a code quality issue

Why We Shouldn’t Design Software the Same Way We Design Physical Things

Backend Engineering Skills Are Emphasized Too Heavily for Principal Engineers