On Thu, Apr 10, 2008 at 6:10 PM, Glenn Ford <[EMAIL PROTECTED]> 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 name. > 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 http://talklikeaduck.denhaven2.com/ _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
