On Sun, Apr 5, 2009 at 1:03 PM, Mark Wilden <m...@mwilden.com> wrote: > On Sun, Apr 5, 2009 at 5:20 AM, David Chelimsky <dchelim...@gmail.com> wrote: > >> Given I register for a conference >> Then my name should be on the list of conference attendees >> And the conference should be my list of conferences > > If I were describing 'register for a conference' in this scenario, > then I would think it important to specify the steps that are used: > > Given I am logged in > And I go to the registration page > And I fill in the email field > And I click "Register" > Then my name should be on the list of conference attendees > And the conference should be my list of conferences > > That's the level of detail the story would have, so that's what I want > to show works. > > On the other hand, this could simply be describing what appears on the > screen when I am registered for a conference (as opposed to how I got > there). In that case, the Given would simply add a database row. But > there would be a different story for the process of filling out the > form. > > Sometimes, they can be combined. But my point is that scenarios still > have to describe how the user relates to the form and 'Given I > register for a conference' doesn't do that. When you do have a > scenario that includes this level of detail, you don't need a view > spec, IMO. And you can still code step-by-step.
It seems that when developers write scenarios they often walk through everything logically and fill in every input field from a scenario. When my customers write scenarios they don't do this, they tend to think higher level. They write: "Given I register for a conference". Over time I've found I lean towards the scenarios remaining higher level. When scenarios too detailed oriented for how "registering for a conference is done" then it becomes a maintenance burden any time how registering for a conference is updated. I like allowing my scenario to remain expressive about the behaviour of the app while leaving out the details about every form field being filled in. In a way it's parallel with refactoring a public method. You can change the details w/o changing how everything uses it. I find that's akin to scenarios. They should only change when the actual behaviour changes (or at least that's my goal to shoot for), not necessarily when the UI gets reworked, or input fields get added or removed. I also don't think the scenario should try to relate the forms on the UI to the user. There are better tools for this job: wireframes, screen mockups, and the actual UI itself. It sounds like you may have an expectation that the scenarios should read like step by step instructions for using the app? An interesting idea, but it adds an additional responsibility to the scenarios which I think will ultimately convolute the value they are trying to express. At least it has when I tried to do that months back. > ///ark > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
