[rspec-users] stepping across features

Andrew Premdas apremdas at gmail.com
Thu Dec 4 01:42:00 EST 2008


It seems to me that there are all sorts of implementation details in this
story that could make your tests quite brittle. And the feature is
definitiley a programmer writing a test, rather than a customer specifying
what they want. Putting on my customer hat

Scenario: Add location
  Given I have a party
  When I set the location
     And I view the party
   Then I should see the location

Starting with this you can then deal with other customer scenario's and work
out what they mean e.g.

Scenario: Change location
Scenario: Add multiple locations
Scenario: Specify location priorities

These may be complex enought to be  new features. allowing you to explore
meaning and business value e.g.  what is the value in prioritising a
location, what happens if there are two main locations etc.

HTH

Andrew

2008/12/3 James Byrne <lists at ruby-forum.com>

> Andrew Premdas wrote:
> > Perhaps the creation of the join is not something that should be
> > tested by a feature. This sounds to me like an implementation detail
> > that would be better tested by some sort of unit test. So if your
> > features want to have things in them mentioning joins, databases and
> > other such things then you're probably using the wrong tool. Joseph
> > wrote a really good blog post about this sort of stuff
> >
> >
> http://blog.josephwilk.net/ruby/telling-a-good-story-rspec-stories-from-the-trenches.html
> >
>
> Thanks for the reference! I have added a link to it from my own attempt
> at describing how to begin testing with cucumber.
>
> I did not show the code because most of it is not written.  I am
> learning as I go with this exercise and no doubt many of these early
> attempts will need to be revised as I become more proficient.  The
> feature looks like this:
>
>  Scenario: Add an initial location for a party
>
>    Given I have a party named "My Test Party"
>
>    When I add a location for "My Test Party"
>      And I set the "type" to "MAIN"
>      And I set the "description" to "Sole Location"
>      And I set the "effective date" to "1984-11-01"
>      And I set the "superseded date" to "nil"
>      And I provide valid site information
>      And I create the location
>
>    Then I should find the "MAIN" location for "My Test Party"
>      And location "description" should be "sole location"
>
> As you can see, other than the attributes and their expected values, the
> only implementation detail exposed is that a site is somehow distinct
> from a location.
>
> In this case, the step definitions [When /have a party named "(.*)"/]
> and [When /provide valid site/] are effectively factory methods that
> provide a valid model instance of the appropriate type.  I was debating
> with myself where best to locate these methods, either in a
> step-definition file relating to the model itself, or as distinctly
> named methods within the location_steps.rb file.
>
> Presently, I am proceeding cautiously with the first option of placing
> these methods with their models, keeping in mind that this may not be
> what I need to do at all.  The main reason being is that the factory
> methods already contained in the model_steps.rb files are working
> without problem.
>
> I am still not content with some of the verbs that I am using in my
> features.  Particularly those surrounding the process of instantiating a
> new row to a table. Add, Create, and Commit all seem to possess
> unfortunate inferences when used in a feature step.
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081204/9cabc6c6/attachment.html>


More information about the rspec-users mailing list