what’s the london school of tdd?

I’ve been hearing about the London school of TDD, and I’m puzzled. This post by Jason Gorman was helpful, but his examples confused me.

In describing classic TDD (as in TDD by Example), he uses as his example a program to express integers as Roman numerals. Then he gives an example for London school (as in Growing Object Oriented Software Guided By Tests) that is bigger, more complex. I’m not sure how to compare them.

I’m wondering whether London-style TDD provides the same advantages as classic TDD. From Wikipedia:

TDD can lead to more modularized, flexible, and extensible code. This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This leads to smaller, more focused classes, looser coupling, and cleaner interfaces.

I’m just starting to read the second book; I’ll know more as I get into it. But I’m really curious: does London school take the same sort of tiny steps that classic TDD advocates? Does it retain the benefits of TDD? I figure you get test coverage, but do you also get emergent design? Simple* design?

* See the four rules of simple design, as explained by Ron Jeffries.

4 thoughts on “what’s the london school of tdd?

  1. Jeff Langr

    I think Gorman’s conclusion is appropriate–”both schools of TDD are at times necessary”–although I’m not sure they need to be so segregated.

    I’d like to know what you think about the Growing OO Software book, by the way. I had a difficult time getting past the example they used.

  2. Jason Felice

    Take all below with a grain of salt. I am still trying to truly understand the London school myself.

    London seems to have an emphasis on _design_, while my own TDD practice, which I shall suppose is Detroit school, and which I started after reading the original Extreme Programming Explained, is primarily focused on _proving the software works_, primarily to reduce _fear of changing the software_.

    If I understand correctly, the London reasoning is that if you test everything in isolation, a badly designed component will be exposed as painful to test, and refactoring to make it easy to test will produce well-designed software, and as a result you will produce well-design, loosely-coupled, SRP-adhering software, which of course will be more robust.

    In contrast, the way I have used TDD is primarily to reduce _fear of changing code_, especially in the long term. As I have practiced it, I don’t aim to describe every component with tests, even though I aim for covering all code paths where possible. I try to test as much as possible through interfaces which are stable to maintain the tests’ durability through design changes.

    As a result, refactoring over the life of the application becomes possible, which allows complexity-reducing changes to happen. This is important: the way I’ve practiced TDD, it’s not so important to produce well-designed code up front – it’s about getting fear-free permission to delete code and change the design later. In fact, the way I’ve practice TDD, it would provide no value without also practicing refactoring.

    My experience with London-school (disclaimer: still much to learn) is that it produces more brittle tests and arguably better-designed (more well-factored code) up front. It seems to produce a lot more testing code, and since mocks and stubs are inevitably coupled with the interface of the thing being mocked or stubbed, interfaces in general seem to become harder to change.

    I’ve heard people at least say that these concerns are addressed by practices in the London school, but I can’t seem to make them work well. I am hopeful that I can learn more about it to add some things to my repertoire.

  3. J. B. Rainsberger

    When I design with interfaces in the London style, I defer details as long as possible and build a system from tiny pieces with well-defined contracts between each layer. Sometimes, I learn that a given layer has become too small to justify its own existence, then I collapse it into a neighboring layer.

    When I design clusters of classes in the Detroit style, I let classes inflate in size until they become obviously overweight, then I split them into smaller classes. I find that I often duplicate tests as I pull a small class out of a bigger class, and I usually want the bigger class to talk to the newly-sprouted smaller class through an interface with a well-defined contract, for which I use test doubles anyway.

    The Detroit style leads me to discover types as I go, and the London style leads me to guess-and-refine types as I go. I’m happy to feel comfortable doing both.

  4. Pingback: Warsztaty CodeRetreat | Blog IT – RafaƂ Roppel

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>