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 <[EMAIL PROTECTED]> > 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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users