>> This actually sounds more confusing to me when viewed in the context >> of my own stories, and it seems similar to what's going on here. I >> write a lot about the user's interaction with the site and what >> should >> happen, so I have a lot of stories that look like: >> >> Given database is in this state >> When user does this stuff in browser >> Then database should be in this new state >> > > This is a very "technical" way to express a scenario. It wouldn't make > much sense to a typical domain expert (unless they know about > databases). > I generally try to write scenarios using the domain language, > focussing on outcomes for users (not computers). Example: > > 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 > > Aslak
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. 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 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 :) Glenn _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
