Chicago TDD vs London TDD – Which one is should you use?

Chicago TDD vs London TDD – Which one is should you use?

Is there one GLOBAL answer or is it dependent on CONTEXT? Does it depend on architecture? On domain?

IMPORTANT: Before reading further, please read my previous post “TDD Dialogue: London School vs Chicago School.”

The following text is my subjective viewpoint based on personal experience.

Business Complexity vs Algorithm Complexity

– Business Complexity (Chicago style): Most software development is enterprise software development – e.g. ordering, reservations, etc. Chicago-style TDD helps us focus on the business requirements, and get to market faster, and refactor as we go.

– Algorithm Complexity (London style): Some software development involves mathematics – e.g. finance, banking, cryptography, operations research, engineering. Business requirements are simple, but the algorithm is challenging. We have to split the problem into multiple parts/stages (e.g. a pipeline). We need to verify each stage of the algorithm separately, we need the granularity. This is where London style shines.

Application Development vs Library Development

– Application Development (Chicago style): Most of us develop applications. The application exposes a series of use cases (behaviors) to the external world, and the external world can’t access the internals. This goes hand-in-hand with Chicago school, testing system behaviors.
 
– Library Development (London style): Here it’s more challenging. There is no use case layer – instead, our library classes are directly exposed! We don’t even though the full set of use cases that could exist. We also need to be more defensive and be able to handle a much wider set of combinations. We need the granularity from the London style.

SUMMARY: Refactorability vs Debuggability

– Chicago style wins when it comes to refactoring. It means, given some business requirements, we can implement the use cases with tests, and we can safely refactor the internals of the use cases without breaking tests all the time.

– London style wins when it comes to debuggability. It means, in cases where we have a need for higher granularity (as is the case for algorithm/mathematical development), that we can work at a more granular level to implement faster and solve bugs faster.

What are your experiences and thoughts? When do you use each style? What kind of industries & applications?

FUTURE: Clean Architecture

In this post, I didn’t address Clean Architecture. I did mention Use Cases, but didn’t go into Domain Entities, Value Objects, etc. Sure, Use Case Driven Development matches well with Chicago school, since use cases are the system behaviors. But what happens with Domain-Driven Design, which places emphasis on the domain models – and domain models are about the structure of the system. I’ll leave that topic perhaps for some future posts.