[rspec-users] Multi-line steps

Rick DeNatale rick.denatale at gmail.com
Thu Apr 10 22:03:38 EDT 2008

On Thu, Apr 10, 2008 at 6:10 PM, Glenn Ford <glenn at aldenta.com> wrote:
Quoting Aslak
>  > Given the customers joe, paul and lisa are registered users
>  > When a user signs up as lisa
>  > Then the user should be informed that the name is taken
>  > And the user lisa should not be able to log in

>  You're right, and I don't literally write them in this format.  But if
>  you interpret the business logic that's in them into what they
>  actually mean technically, it really just is the state of the database
>  and I guess we can also add the session/cookies/flash.
>  Even in the example you just gave, you express in your "Given" that in
>  the Users table of your db there are 3 entries.  For your "When" there
>  is a user interacting with the web app.  "Then" shows that an error is
>  in the response.

Actually, that there are three users with specific user names.

>  You could also check to ensure that the number of Users in the
>  database did not change.  This, I know, is more of a technical way to
>  look at it, but I've personally found use for this when realizing a
>  tricky view was passing bad data to a controller and my Story caught
>  it.  It was getting the right flash message in the end... but there
>  were too many entities being created in the db.  I didn't catch this
>  until the Story spec so I still think there's a use for this!
>  You could even break apart "And the user..." into:
>   When a user tries to log in as lisa
>   Then the user should be informed that no such customer exists

Which if you step back and look at the whole story is problematic,
because, as I tried to point out, perhaps a bit too tongue in cheek,
'Lisa' here is ambiguous.

There is one Lisa who is already a registered user, and a second one
who tries to use the name which is already taken.

And I wouldn't think that most reasonable systems would disable
Lisa1's account because some Lisa2 tried and failed to  use the same

>  Because really the current statement includes multiple steps.  Going
>  to the login page, filling out the data, submitting it, and then
>  checking the response/redirect.  If there were an error in your "Then
>  the user $lisa should not be able to log in" step, it would be
>  untested and it's actually not quite trivial since it's not a single
>  step.  That's probably more nit-picky since I'm sure the step would be
>  used in many other places to give you added confidence, but since you
>  mentioned "When" is for actions and your example "And Then" has an
>  action, I still think it's interesting to look at :)

And to make the distinction between Given's,  When's and Then's
fuzzier, there's GivenScenario, which effectively converts all of a
scenario's Givens, When's and I guess Then's into a Given for a
subsequent scenario.

Rick DeNatale

My blog on Ruby

More information about the rspec-users mailing list