TDD - classicist vs. London Style
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.
-
[Polymorphism and Multimethods]
02-03-2023 -
[Global Day of CodeRetreat - recap]
07-11-2022 -
[House automation tooling - Part 4 - Finalized]
01-11-2022 -
[House automation tooling - Part 3 - London-School and Double-Loop]
02-07-2022 -
[Modern Programming]
14-05-2022 -
[House automation tooling - Part 2 - Getting Serial]
21-03-2022 -
[House automation tooling - Part 1 - CL on MacOSX Tiger]
07-03-2022 -
[Common Lisp - Oldie but goldie]
18-12-2021 -
[Functional Programming in (Common) Lisp]
29-05-2021 -
[Patterns - Builder-make our own]
13-03-2021 -
[Patterns - Builder]
24-02-2021 -
[Patterns - Abstract-Factory]
07-02-2021 -
[Lazy-sequences - part 2]
13-01-2021 -
[Lazy-sequences]
07-01-2021 -
[Thoughts about agile software development]
17-11-2020 -
[Test-driven Web application development with Common Lisp]
04-10-2020 -
[Wicket UI in the cluster - the alternative]
09-07-2020 -
[TDD - Mars Rover Kata Outside-in in Common Lisp]
03-05-2020 -
[MVC Web Application with Elixir]
16-02-2020 -
[Creating a HTML domain language in Elixir with macros]
15-02-2020 -
[TDD - Game of Life in Common Lisp]
01-07-2019 -
[TDD - classicist vs. London Style]
27-06-2019 -
[Wicket UI in the cluster - reflection]
10-05-2019 -
[Wicket UI in the Cluster - know how and lessons learned]
29-04-2019 -
[TDD - Mars Rover Kata classicist in Scala]
23-04-2019 -
[Burning your own Amiga ROMs (EPROMs)]
26-01-2019 -
[TDD - Game of Life in Clojure and Emacs]
05-01-2019 -
[TDD - Outside-in with Wicket and Scala-part 2]
24-12-2018 -
[TDD - Outside-in with Wicket and Scala-part 1]
04-12-2018 -
[Floating Point library in m68k Assembler on Amiga]
09-08-2018 -
[Cloning Compact Flash (CF) card for Amiga]
25-12-2017 -
[Writing tests is not the same as writing tests]
08-12-2017 -
[Dependency Injection in Objective-C... sort of]
20-01-2011