What is the Outside-In TDD approach?

Outside-In TDD (also known as London School TDD or "Mockist TDD") starts from the outside (acceptance/integration level) and works inward, using mocks to define collaborator interfaces. Contrast with Inside-Out TDD (Chicago/Detroit School) which starts with domain objects and builds up. Outside-In workflow: (1) Write a failing high-level acceptance test (E2E or integration). (2) Write a failing unit test for the outermost class (controller/handler). (3) Mock collaborators (services, repositories) — this defines their interface. (4) Make the unit test pass. (5) Write unit tests for mocked collaborators, repeat down the stack. (6) Eventually, the acceptance test passes. Benefits: design emerges from requirements outward; interfaces are designed from the consumer's perspective. Downsides: heavy use of mocks can create brittle tests tied to implementation; requires discipline to avoid over-mocking. Inside-Out TDD is better for domain logic; Outside-In for systems with clear interface contracts. Many practitioners combine both — start outside for overall direction, go inside-out for domain core.