[blog] | [projects] | [about] | [imprint]

TDD - classicist vs. London Style

27 June 2019
 

OK, I don't want/need to explain TDD.

As for 'Outside-in', it is a development approach where you start developing at the boundary of a system on a use-case basis.
This can be a web service, a web page, a CLI interface or something else.
You could say that it's a vertical slice through the system where you add the behavior for the use-case.

But you start your coding with an integration test which expects the right outcome, but since nothing is coded yet it will fail until the very end.
The integration tests makes sure that all components are eventually properly wired together, and can produce the side-effect or direct outcome that is expected.

So what is 'classicist'?

With 'classicist' we mean the original TDD approach or red-green-refactor cycle and triangulation where the production code is developed in small steps.
In between (in the refactor step) you want to do refactorings and carve out collaborators, find abstractions, etc.,
but your tests should not be changed once they were green. The refactorings you do are internal, not externally visible.
Your tests implicitly test the behavior of helper classes like collaborators.
You don't usually do a lot of mocking, in particular not of the collaborators.

'London style' 

'London style' is different in that you explicitly think about any collaborations and helper classes while you write the test.
So you do more during the 'red' step and therefore the yellow (refactor) step is shorter than in classicist.
As a consequence you have to mock out those collaborators, because you know about them and want to control them.
On a new system you can carve out a lot of the architecture and design this way.

So basically, while 'classicist' drives design passively and as a refactoring, 'London style' drives it actively through mocking.

Some say that this ('London style') actually tests internals, which you should avoid.
But I think we have to look at this from a different perspective.
As a tester and designer I would want to know which classes collaborate and use other classes. And this is satisfied by the mocking.

[atom/rss feed]