[rspec-users] Role of stories vs specs
dchelimsky at gmail.com
Sun Nov 18 05:43:40 EST 2007
On Nov 14, 2007 5:50 PM, Pat Maddox <pergesu at gmail.com> wrote:
> On Nov 13, 2007 4:00 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On Nov 13, 2007 5:17 PM, Pat Maddox <pergesu at gmail.com> wrote:
> > > Let's say in some banking software we have a transfer screen, and
> > > there are three possible errors: insufficient funds, source account
> > > frozen, target account frozen. Would you write a scenario for each of
> > > the possible errors, and an example for each?
> > Without even batting an eye!
> > The scenario is going to reflect how things look from the outside. The
> > example is going to be targeted right at the part of the system that
> > is responsible for producing the correct error message.
> When I gave that example I thought it sucked, because I would write a
> story and example for each too. But I guess I can say it served as a
> bit of a sanity check.
> Anyway, a more gray-area example (imo) is Rails validations. We've
> got a user registration page, and it requires the user to fill in
> their name, email address, and a password.
> Would you write a scenario where nothing is filled in? Where
> everything but the name is filled in? And so on for each attribute.
> How about combinations of missing stuff?
> It seems to me like that story is on a VERY high level and all we
> really care about is verifying that the plumbing works (so maybe I
> need to think of this as a story for the UI domain instead of the
> business domain?). If the user fills in everything, make sure there's
> a new record. If they don't fill it in, make sure they're shown the
> registration page again. It's cumbersome to try to cover every
> possible scenario even though you "should."
> Would you write a story at a lower level, which actually tries to save
> the objects to the db and verifies that nothing changes? That
> *definitely* duplicates what's going on in the model-level specs.
Keep in mind that stories/scenarios and specs each play multiple roles.
Scenarios start off as a collaboration tool for the whole team to
understand what's about to be developed. Then code is developed, the
scenarios pass, and now they serve two new purposes. Assuming they are
well maintained (they are kept well organized and passing), scenarios
document the system as it actually is and they are system-level
Similarly, examples start as a means of designing subsets of the
system at a very granular level. Then the become documentation of your
objects as they really are, and object-level regression tests.
Also consider that both levels have a red/green/refactor life cycle,
though less apparent at the higher levels. So they are both constantly
subject to change in response to new and changing requirements. But
they have subtly different forces of change. At a high level, they are
both changing because the business rules grow or change. But specs
change much more frequently as the design changes.
In the end, it's about finding a process that works for you and your
team throughout the lifecycle of a project. For me, the duplication
between stories and specs helps me to stay productive all the time. It
is faith in combination of the two alerting me of behaviour-breaking
changes that keeps me moving.
If on your team you find it more pragmatic to express things in one
place or the other, and you find that doing so keeps you agile
(remember - agility is not only about speed - it's about responding to
change) throughout the project, then that's OK.
My experience tells me that I'm a happier person when I've got robust
sets of stories and specs that live independently and both cover the
entire system from their unique perspective.
> Hopefully this thread hasn't died...
No - it was just on vacation. Though I would welcome more voices in it
if anybody else has an opinion to express.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users