I like London School TDD - it feels more like a proper framework for emergent design than Classic TDD, although I imagine, as Fredrik says, you won't use one style exclusively.
My nagging concern is that, once I've written my tests, they always look quite trivial. I feel with Classic TDD that I treat the class under test as a black box, whereas with London School I end up taking more of a white box view. I wonder what I am really testing.
Co-incidences :) Am on the travel for giving a two-day in-house course on testing (using pytest) and a major part of the exercises is going to cover and discuss mocks. I tend to discourage people from using mocking as much as possible. Testing collaborations can be an exception i guess.
I often don't use Mocks but Stubs (using Mocking tools). In my experience tying your test to the exact calls in your code, makes them rigid and refactoring hard.
The reason to use Mocks is for design, the test can then really drive your design process. The essential consequence that everyone misses is that the test should be removed when you're done.
Fredrik - I agree you could use both styles in the same system, depending on context. Would like a better elaboration of what you see as a "worker" class vs a "manager" class
Ian - I think I'll be taking up issues around white/black box more in the third article in this series I'm planning.
Holger - sounds like you're doing classic TDD then :-)
Machiel - If you're using tests purely as a design tool and they give no regression protection then you could remove them I guess. I don't see many expert London School practitioners removing all their tests afterwards, although I think they may prune more than classic TDDers. Not sure on that point.
6 comments:
I really see it as "as you work your way through /managers/ down to /worker/ classes", you move from mocking to classical style.
I like London School TDD - it feels more like a proper framework for emergent design than Classic TDD, although I imagine, as Fredrik says, you won't use one style exclusively.
My nagging concern is that, once I've written my tests, they always look quite trivial. I feel with Classic TDD that I treat the class under test as a black box, whereas with London School I end up taking more of a white box view. I wonder what I am really testing.
Co-incidences :) Am on the travel for giving a two-day in-house course on testing (using pytest) and a major part of the exercises is going to cover and discuss mocks. I tend to discourage people from using mocking as much as possible. Testing collaborations can be an exception i guess.
Looking forward to more insightful posts :)
I often don't use Mocks but Stubs (using Mocking tools). In my experience tying your test to the exact calls in your code, makes them rigid and refactoring hard.
The reason to use Mocks is for design, the test can then really drive your design process. The essential consequence that everyone misses is that the test should be removed when you're done.
Thankyou for your comments!
Fredrik - I agree you could use both styles in the same system, depending on context. Would like a better elaboration of what you see as a "worker" class vs a "manager" class
Ian - I think I'll be taking up issues around white/black box more in the third article in this series I'm planning.
Holger - sounds like you're doing classic TDD then :-)
Machiel - If you're using tests purely as a design tool and they give no regression protection then you could remove them I guess. I don't see many expert London School practitioners removing all their tests afterwards, although I think they may prune more than classic TDDers. Not sure on that point.
Fredrik - does this article describe what you mean by managers & workers? He calls them "Sergeant" and "Private" methods:
http://feelings-erased.blogspot.se/2013/01/single-method-perspective-vs-single.html
Interesting article, in any case
Post a Comment