Warning - bit of a ramble below!
On 29/01/2008, Edvard M. [email protected] wrote:
If I remember correctly, Dave A. wrote something along these lines
in his book Test Driven Development
(reminding that BDD is TDD done right): create a TODO list of small
tasks to do, related to roles of the object, and pick something
start writing tests.
You make some good observations.
The advice to “pick something and start writing tests” was one of the
bells early on that told me TDD was about more than testing. I write
software to solve a problem - especially commercial software - and there
usually a stakeholder involved who wants to see tangible progress.
With respect, BDD is more than TDD-done-right. “Full-scale” BDD
the outside with stories and scenarios and working inwards to the code)
out of trying to identify “the next most important thing” from the
stakeholder’s perspective, rather than whatever looked most interesting
me as a programmer.
If you only have the close-up view of TDD - or example-level BDD (which
unfortunately is what most people consider BDD to be) - it’s difficult
see what the most valuable behaviour would be, and therefore the next
important thing to implement, so you end up choosing “somewhere
(i.e. somewhere arbitrary in business terms). Without business-level
acceptance criteria in the form of scenarios you don’t know what “done”
looks like, so it’s very tempting to capture a whole bunch of things
occur to you in case one of them is the way forward. That’s when you
yourself writing a bunch of “todo” or pending examples.
If you start with a narrow, end-to-end piece of functionality and drill
it from the outside, right through until you have it working, you will
that at each layer of abstraction you will have a pretty focused subset
behaviour to implement to get the job done.
IMO, if you don’t think of the features at all and just start to spec
completely some single functionality, you risk rewriting that test
when you add new tests for other methods on the same object, no?
You certainly risk revisiting something many times - often assumptions
made in speccing out the object without any outside-in forces to
its actual value. If I’m honest, I find myself doing this more often
would like, especially when I’m reworking legacy code (which is a lot of
time recently). I usually take it as an indication that I haven’t
my scope enough - I’m not “outside” enough to have a reasonable
I stop, take a couple of steps back (usually reverting all my recent
changes!) and reassess exactly who is the client of the code I’ve been
I can relate to your point about writing a few examples to help you
understand how an interface might work. Massaging code like that is a
way to explore an API. The important thing is to recognise it as just
an exploratory exercise. Then you throw away any code you created in the
process and start over, outside-in, armed with the knowledge that came
of the spike.
Perhaps I ought to write this up - it’s a theme that comes up quite
Thanks for listening,