[rspec-users] [Cucumber, BDD] When not to use Cucumber?

Brent Snook brent at fuglylogic.com
Sat Jan 24 00:04:00 EST 2009


I've been using story runner for the first time over the past 4 months or so
and I've found the invaluable part to be the plain text support. Having a
shared artifact that can be used by the customer, developers and testers is
a huge boost towards achieving ubiquitous language. We use the story kickoff
discussion to refine the language used in each scenario together, ensuring
that the language makes sense to everyone and is consistent with other
stories.

In the sense that we want a way to store the feature/story in an executable
format that we can all understand, a tool that supports plain text stories
is the best choice for us. You can implement a scenario just as easily using
plain rspec but then it becomes less accessible to other people in the team.


If I was choosing a testing approach for a project that had technical people
as customers I would still use the GWT format. I think it helps you
continually focus on what you are really trying to achieve, otherwise it can
be too easy to burrow down into the technical details and lose sight of
that. No matter what the nature of project, every thing that you do is
driven by the goal of adding some sort of value. Continually keeping that
goal in mind helps you make better choices along the way.

I agree with James that having that separation between the "what" and "how"
is very useful. This approach is amenable to a more black box style of
testing appropriate for acceptance tests. You should theoretically be able
to completely change how your system works without touching the
story/feature text. Your mileage would of course vary with this depending on
whether or not you use a more declarative or imperative approach (as Ben
describes in
http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/
).

My current recipe for testing spread is to automate the acceptance scenarios
using a tool like story runner/cucumber and then use specs for targeted
integration and unit level testing. The automated acceptance scenarios cover
the main scenarios that the customer cares about while more specialised
cases (or more technical aspects) are covered at the spec level. The specs
will typically gravitate towards the white box end of the scale (describing
the internals in more detail).

- Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090124/cf69431b/attachment-0001.html>


More information about the rspec-users mailing list