Are You Chicago Or London When It Comes To TDD?

Summary

In this video, Dave Farley explores the two primary schools of Test-Driven Development (TDD): the Chicago School and the London School. He explains the differences in their approaches, with the Chicago School focusing on state and bottom-up testing, and the London School emphasizing interactions and top-down design. Farley highlights the role of mocks and test doubles, offering insights on how to use these tools effectively. Ultimately, he advocates for a hybrid approach, combining the strengths of both schools to create more efficient and flexible TDD practices. This video provides valuable insights for developers looking to refine their testing strategies.

Takeaways

• 😀 Test Driven Development (TDD) has two main schools of thought: the Chicago (Classicist) School and the London School, each with its distinct approach.
• 😀 The Chicago School focuses on testing individual methods, checking state changes and return values, using a more pragmatic and bottom-up design approach.
• 😀 The London School drives design from the top-down, using high-level acceptance tests (often in BDD style) and focusing on interactions between system components.
• 😀 There is no major conflict between the two schools; they are just different approaches that can be combined depending on the situation.
• 😀 The Chicago School emphasizes real, production code in unit tests, focusing on the behavior of components like a bookshop and warehouse.
• 😀 The London School encourages the use of mocks and stubs to abstract away dependencies and test interactions more flexibly, especially when the real code or components aren't ready yet.
• 😀 The use of mocks in the London School allows for testing before real implementations exist, speeding up development when working in uncertainty.
• 😀 While mocks can be powerful, their misuse can lead to overly complex tests and poor design. If mocking becomes complex, it often signals design flaws.
• 😀 Both schools of thought stress the importance of maintaining a separation of concerns in code design to ensure better testing and maintainability.
• 😀 The London School allows for faster progress when you're unsure about the system's design by testing abstractions rather than concrete components.
• 😀 A hybrid approach combining elements from both schools (Chicago and London) is often the most effective, allowing developers to adapt to the specifics of their project.

Q & A

What is the main difference between the Chicago School and the London School of Test-Driven Development (TDD)?

The Chicago School focuses on testing the state of the system by verifying return values and state changes in real objects, while the London School emphasizes interaction testing, using high-level acceptance tests to drive design and employing mocks and test doubles to isolate dependencies.

Why does Dave Farley reject the idea of a 'war' between the Chicago and London schools of TDD?

Farley believes that the differences between the two schools are not as radical as often portrayed. He suggests that both approaches have valuable techniques that can complement each other, and there's no need to choose one over the other. Instead, he advocates for a hybrid approach.

What does the Chicago School's approach to TDD focus on, and how does it impact system design?

The Chicago School focuses on verifying the state of the system by interacting with real objects and checking return values. This approach tends to result in a more bottom-up design, where individual components are tested in isolation before being integrated into the system.

How does the London School's approach to TDD differ in terms of design and testing?

The London School drives design from the top down, using high-level acceptance tests to dictate the overall behavior of the system. It focuses more on testing the interactions between components rather than their individual states, and it makes heavy use of mocks and test doubles to simulate dependencies during tests.

What role do mocks play in the London School of TDD, and why are they important?

Mocks in the London School are used to simulate external dependencies when testing individual components. This allows developers to focus on interactions rather than the internal state of real objects, facilitating test-driven design even when dependencies are not fully implemented or clear.

Why does Farley suggest that using mocks too extensively can be a sign of poor design?

Farley argues that overusing mocks can indicate that the system is too complex or poorly designed. If a test requires an overly complicated setup with many mocks, it suggests that the system may have too many interdependencies or that the design could be better structured to minimize these dependencies.

What is Farley's 'Mid-Atlantic approach' to TDD?

The Mid-Atlantic approach combines elements from both the Chicago and London schools of TDD. Farley suggests using high-level acceptance tests (London School) to drive the overall design while also testing individual components at the unit level (Chicago School), blending the strengths of both methods.

What is the significance of acceptance testing in the London School of TDD?

Acceptance testing in the London School is crucial because it helps drive the overall system design by focusing on system behavior at a higher level. It also provides a way to test interactions between components and verify that the system as a whole behaves as expected before moving to more detailed unit tests.

How does the use of dependency injection relate to the Chicago and London schools?

Dependency injection plays a role in both schools, though more clearly in the Chicago School when testing real objects. In the London School, it supports the creation of mocks and test doubles by allowing dependencies to be easily substituted during testing, helping to focus on interactions rather than the state of concrete objects.

What are the risks of testing external systems (like databases or UIs) directly in low-level unit tests, according to Farley?

Farley warns that including external systems such as databases or UIs in low-level unit tests can lead to slower, more fragile tests. It can also make tests harder to control, as real I/O operations introduce variability and external dependencies. The London School helps avoid this by abstracting these external systems and using test doubles to simulate interactions.