[rspec-users] stepping across features
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.
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users