[skatenerd]

This resource is clearly-written, and it distills what a lot of what people gradually learn over years of practicing TDD.

There is a lot of solid reasoning (and examples) leading up to this point, but one notable point was this conclusion:

``` [London-school TDD] sits at the extreme end of the trade-off between coupling and design feedback: incredibly rich feedback about the design of the system, typically resulting in small, hyper-focused units with carefully-chosen naming and easy-to-use APIs. They come at the cost, however, of significantly decreased freedom to refactor the implementation aggressively, which is why Discovery Testing recommends developers default to deleting-and-redeveloping local sub-trees of dependencies when requirements change significantly. This can result in reliably comprehensible designs, but with an increased base cost to requirement changes. ```

I really agree with this. I spent a few years working with a consulting company which preaches London-school TDD. We did a lot of work in dynamic languages, and refactoring was particularly difficult because we had to make sure that all of our mocks (and other test code) lined up with the refactored APIs.

I hate to take the discussion here, but I wonder how Static Typing changes the experience of London-school TDD. Does it become easier and less-frustrating to refactor your test-code?

[kyllo]

Naturally it does, because a good typechecker is like an automatic test suite that guides you through refactoring. It means you need fewer unit tests, which means less test code to maintain.

I am working on a Rails project and a Haskell project simultaneously; the Haskell project requires far fewer tests because the compiler can catch so many potential bugs. Then when you add ghci (Haskell REPL) it becomes almost as flexible and exploratory as a dynamic language. Some Haskellers even like to say that TDD stands for Type-Driven Development. Combine that with REPL-driven development, add in property-based generative testing with Quickcheck, and you have a lot of very powerful tools to help you build the thing right.

[collyw]

So now you can't refactor your test driven code. I though that was one of the benefits of unit tested code - it made refactoring much easier.

[searls]

That is an incorrect assumption if it's made universally. The answer is that it depends on what you're testing, why, and how. It also means what you mean by refactor.