For a more realistic example lets take the leasing application I worked on. There were lots of rules and formulas, and exceptions to those rules and formulas, and the different pieces were (sometimes) part of larger calculations. We specified the requirements in the normal declarative fashion
On Wed, Jan 7, 2009 at 9:00 PM, Pat Maddox <perg...@gmail.com> wrote: > On Wed, Jan 7, 2009 at 6:22 PM, Stephen Eley <sfe...@gmail.com> wrote: > > On Wed, Jan 7, 2009 at 7:00 PM, Steve Molitor <stevemoli...@gmail.com> > wrote: > >> Lots of features use the word "should" in their then clauses. > >> Take this example from the 'Feature Introduction' of the cucumber wiki: > >> > >> Scenario: Buy last coffee > >> Given there are 1 coffees left in the machine > >> And I have deposited 1$ > >> When I press the coffee button > >> Then I should be served a coffee > > > > Maybe I'm overly audacious, but I'd call that imprecise wording. A > > better clause would be "Then I am served a coffee." > > meh. I use "should" all over the place in my features. > > > >> Should this be an rspec example instead? It certainly could be, but I > don't > >> think an rspec example would communicate as well with the customer as > the > >> feature would. And that's the primary goal here (as Pat and Matt have > >> reminded me!). > > > > I agree. This is a flawed feature, but it really ought to be a > > feature: it describes a stimulus (an action) and a response. But this > > example doesn't have much in common with your original e-mail > > validation example. In that case, what's the action and what's the > > response? And is a feature clearer to the customer to explain e-mail > > validation than a spec? > > hrm... > "pat.mad...@gmail.com".should be_valid_email > "pat.maddox+...@gmail.com <pat.maddox%2b...@gmail.com>".should > be_valid_email > "pat.mad...@gmail".should_not be_valid_email > > Seems pretty clear to me. > > Email validation and the lease cost formula are examples of acceptance > tests that are probably best handled with FIT. I know that cucumber > has FIT-inspired tables, but those are still coupled to scenarios, > aren't they? > > Actually, I'd still prefer to write these tests with prose. But it'd > be super simple: > > pat.mad...@gmail.com is a valid email address > pat.mad...@gmail is an invalid email address > > You can achieve this with cucumber already... > Then pat.mad...@gmail.com is a valid email address > Then pat.mad...@gmail is an invalid email address > > but it looks stupid. > > Pat > _______________________________________________ > 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
