[rspec-users] Multi-line steps
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:
> > 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
My blog on Ruby
More information about the rspec-users