London vs Chicago: The two ways of TDD 🔀
Whenever you get closer to TDD, you discover that two main approaches (schools) exist: they are called London School and Chicago School. But what are the differences? Let’s see it together!
Introduction
Hello, developers! 🚀
We go back to talk about Test-Driven Development (TDD) today, with a little twist — we’re exploring the two main different approaches of the two iconic TDD schools: London and Chicago.
Each TDD school brings its unique flavor to the table, offering a different perspective on how to approach software testing and development with TDD. In this article, we’ll describe the two approaches and compare them.
In an imaginary travel from America to England, let’s see what London and Chicago Schools have to offer for TDD practitioners.
Let’s dive in! 💻✨
A Tale of Two Cities
First of all, I want to make sure everyone knows what I’m referring to when I mention London or Chicago schools.
When we first meet TDD, we typically first see it via the Chicago School: a.k.a. Detroit School, this school follows an Inside-Out approach; this provides a more exploratory, state-based way to solve the problem by starting from the inside of the application (from the core domain models, for example) and works out towards the APIs.
Most of the time, this is the typical approach I see when it comes to tutorials and examples online, especially those for beginners — probably just because it’s easier to start making examples on small pieces of code and then putting them together afterward.
Usually, the pros and cons of the Chicago School are considered to be:
Pros
- since typically the collaborators we need already exist, It’s easier to keep tests decouples from the implementation, and the use of Test Doubles is minimized
- It’s easier to have a higher cohesion because we start with very specific tests to more generalized ones — and this promotes high cohesion
Cons
- It’s harder to respect the YAGNI principle and avoid over-engineered solutions — while TDD still reduces these risks, going from the inside to the outside can still bring to some of these situations because you look at the higher level later
The London School, on the other hand, follows the opposite Outside-In approach; this provides a formal, behavior-based way to solve the problem by starting from the outside of the application (from the APIs or controllers, for example) and working its way through the lower layers.
This school is called in multiple ways (Mockist TDD, or the most famous ATDD, which stands for Acceptance Tests Driven Development) and is the approach that you typically face after you start being fluent with TDD in general.
Usually, the pros and cons of the London School are considered to be:
Pros
- It’s an approach more focused on the behavior of the application and the interface used by the user — like in Contract-First API development, you start by thinking about how the client will interact with your code, and then move more on the inside later
- CQS (Command-Query Separation principles) is easier to implement: CQS is an approach that promotes classes that have only methods that either read data or change data, which improves readability and maintainability
Cons
- Higher risk of more fragile tests: starting from the outside will require using mocks to replace the collaborators we need and still don’t exist; we need to be careful and use best practices here to ensure that we don’t tight too much to the implementation, otherwise our tests will break at every change; one example? Favor manual written Fakes and Spies instead of Stub and Mocks set up with mock libraries
- Refactoring might be harder: for the same reason, if we tighten too much our tests to the implementation, every refactoring will also require changing tests — and this is just wrong since refactoring should be done by never breaking our tests; be careful with those mocks!
[ … continue … ]
Until next time, happy coding! 🤓👩‍💻👨‍💻
🙏 Thank you for reading this shortened version of this article. You can enjoy the full version on my blog here.
