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

Zach Dennis zach.dennis at gmail.com
Sun Apr 5 14:16:15 EDT 2009

On Sun, Apr 5, 2009 at 1:03 PM, Mark Wilden <mark at mwilden.com> wrote:
> On Sun, Apr 5, 2009 at 5:20 AM, David Chelimsky <dchelimsky at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Zach Dennis

More information about the rspec-users mailing list