[rspec-users] Best practices: How small to make examples?

David Chelimsky dchelimsky at gmail.com
Sun Apr 5 16:37:39 EDT 2009

On Sun, Apr 5, 2009 at 3:05 PM, Mark Wilden <mark at mwilden.com> wrote:
> On Sun, Apr 5, 2009 at 11:16 AM, Zach Dennis <zach.dennis at gmail.com> wrote:
>> 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".
> My customers give me mockups and indeed specify what fields must be filled in.
>> 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.
> Fine, but then you've shifted the maintenance burden to your view specs.

View specs the domain of me and my co-developers. We are free to
maintain them using all the knowledge that we have about maintaining
code. Shifting the burden away from the scenarios to view specs
actually reduces the overall cost, in my view, as we don't need to
have a meeting every time I want to refactor something.

>>  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 many cases, if not most, what the user types is part of the
> behavior of the app. Not for merely descriptive information - agreed.
> But in my current app, most fields lead to differences in behavior.
> E.g., the challenge is public, Zach has been invited to it, it expires
> on a certain day, etc. I consider this information essential to the
> behavior of the app, not "merely" the UI.
> Of course, I've always felt that the UI is the most important part of
> the app, anyway. I feel that if certain user actions lead to certain
> physical output, then I've fufllled the requirements of the app.
>> 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.
> You have to test this stuff somewhere. And perhaps I'm just
> old-school, but to me, a user story does indeed specify what the user
> does. If it's too general, that makes its acceptance criteria
> problematic.

It's not about old-school or new-school or any school. It's about the
individual needs of your team, and what it is you need to communicate.
What you're doing is perfectly fine if the details of every
interaction need to be communicated at this level.

Also, this isn't necessarily an all or nothing deal. One way I've
approached this that works well is to have a single scenario that
describes the details we're talking about, and a lot more scenarios
that are more declarative. Now you have the best of all worlds.


> ///ark
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list