It describes an entirely different approach to test-driven development from its predecessor,
the GOOS’s authors, Nat Pryce and Steve Freeman,
consistently arrive at clean, minimal designs of small, focused units of code
a London-school unit test suite only provides regression safety of each unit in isolation, it’s typically necessary to have a second, minimal suite of end-to-end tests that validate the system works when everything is wired up and integrated.
London-school TDD encourages programmers to use external constraints as a starting point
Typically, systems designed with London-school TDD demonstrate greater emphasis on design patterns, object-oriented design, and domain-driven design. The greatest risk posed by this approach is YAGNI resulting from APIs that wind up being a poor fit for the integrated code that would actually call it (e.g. mismatched parameters, differing return types, etc.)
gateway drug to functional programming, because it encourages separating code with side effects and maximizing pure functions.
An interesting consequence of practicing London-school TDD is that the design of each unit is not only heavily-influenced by its test and the overall testing workflow, but that the shape of each unit will typically resemble one of a handful of archetypes. Incidentally, each of these archetypical object patterns have some favorable design characteristics
mocked-out dependencies (like Collaborator and Signaler) require significantly more effort to refactor significantly.