rspec users - Feb 2008 - outside-in BDD vs writing examples up front

I thought I''d repost this because it had the not-very-obvious title of
"Re:
Textmate RSpec Bundle ''it'' snippet". And it seems quite
timely wrt the BDD
vs TDD threads.

Cheers,
Dan

ps. Not wishing to single out Edvard below - I just happened to reply to his
message in the original thread.

---------- Forwarded message ----------
From: Dan North <tastapod at gmail.com>
Date: 29 Jan 2008 23:35
Subject: Re: [rspec-users] Textmate RSpec Bundle ''it'' snippet
To: rspec-users <rspec-users at rubyforge.org>

Warning - bit of a ramble below!

On 29/01/2008, Edvard Majakari <edvard at majakari.net>
wrote:
>
> > Not if you fill it out...and the BDD way is to write one example at a
> > time, not a complete spec beforehand.
>
> I''ve done it this way too (being lazy), but is it really good
thing?
> Often I get more insight on how an interface should look like,
> if I think even superficially what kinds of services an object should
> offer. Thus I _think_ that writing a TODO-list in spec form
> (marking all as pending) and starting to pick up those that you want
> to do. Is this really considered non-BDDish by the authoritatives?
>
> If I remember correctly, Dave Astels 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
alarm
bells early on that told me TDD was about more than testing. I write
software to solve a problem - especially commercial software - and there is
usually a stakeholder involved who wants to see tangible progress.

With respect, BDD is more than TDD-done-right. "Full-scale" BDD
(starting at
the outside with stories and scenarios and working inwards to the code) grew
out of trying to identify "the next most important thing" from the
stakeholder''s perspective, rather than whatever looked most interesting
to
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
to
see what the most valuable behaviour would be, and therefore the next most
important thing to implement, so you end up choosing "somewhere
interesting"
(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
that
occur to you in case one of them is the way forward. That''s when you
find
yourself writing a bunch of "todo" or pending examples.

If you start with a narrow, end-to-end piece of functionality and drill into
it from the outside, right through until you have it working, you will find
that at each layer of abstraction you will have a pretty focused subset of
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
> many times
> when you add new tests for other methods on the same object, no?

You certainly risk revisiting something many times - often assumptions you
made in speccing out the object without any outside-in forces to identify
its actual value. If I''m honest, I find myself doing this more often
than I
would like, especially when I''m reworking legacy code (which is a lot
of my
time recently). I usually take it as an indication that I haven''t
broadened
my scope enough - I''m not "outside" enough to have a
reasonable perspective.
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
tinkering with.

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 great
way to explore an API. The important thing is to recognise it as just that -
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 out
of the spike.

Perhaps I ought to write this up - it''s a theme that comes up quite
often.

Thanks for listening,
Dan

--
> "One day, when he was naughty, Mr Bunnsy looked over the hedge into
> Farmer Fred''s field and it was full of fresh green lettuces. Mr
> Bunnsy, however, was not full of lettuces. This did not seem fair."
>   -- Terry Pratchett, Mr. Bunnsy Has An Adventure
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20080204/751c4791/attachment.html

This is a short reply, but thinking about it a bit deeper, I have to
agree with Dan. What especially caught my
attention was this piece:
> If you start with a narrow, end-to-end piece of functionality and drill
into
> it from the outside, right through until you have it working, you will find
> that at each layer of abstraction you will have a pretty focused subset of
> behaviour to implement to get the job done.
I think this comment is brilliant, as it is a more concrete viewpoint of
what "BDD manifesto" mentions about business value
(http://behaviour-driven.org/WheresTheBusinessValue).

As it happens, one of my main concerns with TDD was that it didn''t
seem to have any strong opinions or rules about

  a) order of writing specifications regarding level of abstraction or
architectural structure (eg. I prefer V, C, M spec order in Rails, as
it starts from what the supposed client would see)

  b) how to pick the first test/spec you are going to implement.

Dan, I think your post gave an excellent answer (well, at least one)
to those questions -- and it also seems to be an opinion popular among
those few BDD practitioners _I know_ of; outside-in practically clears
out part a), as you are starting with high-level stuff like stories,
going deeper driven by requirements of higher level entities. Part b)
becomes much easier when you think about the clients priorities: what
feature gives the most business value for the client at the moment?
When starting an issue tracking system from the scratch, probably the
ability to submit new tickets becomes first -- that is, even before
being able to view them. Though quite obvious in retrospective, the
emphasis on business value in BDD gives IMO extra structure and
support for otherwise rather chaotic field of software engineering,
especially when the idea is applied in concrete rules of the
methodology.

Thanks!

-- 
"One day, when he was naughty, Mr Bunnsy looked over the hedge into
Farmer Fred''s field and it was full of fresh green lettuces. Mr
Bunnsy, however, was not full of lettuces. This did not seem fair."
  -- Terry Pratchett, Mr. Bunnsy Has An Adventure