[rspec-users] Role of stories vs specs

Pat Maddox pergesu at gmail.com
Wed Nov 14 18:50:26 EST 2007

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.

Hopefully this thread hasn't died...


More information about the rspec-users mailing list