I hid send to early on a previous email; please ignore it. I think you could do this with cucumber:
Then <email> should be a <result> email address | date | result | | "s...@foo.com | valid | | "tom@" | invalid | Or: Then <email> should be a valid email address | email | | s...@foo.com | | t...@bar.com | Then <email> should be an invalid email address | email | | sam@ | | @bar.com | I don't think you need all three steps. Instead of the tables you could And them all together if you prefer. OK, "Then" is a little awkward. Perhaps you could monkey patch cucumber with your own step name. I may have picked bad examples, but fundamentally I don't think this is an rspec vs. cucumber issue. In the leasing app I worked on we had lots of testing scenarios like 'setup the lease with values x, y, z..., then press the calculate button. The result should be xxx'. Obviously these translate directly into cucumber scenarios. And then some tests would include other tests, as caculcations were often composites of other calculations. I could see where sometimes inlining would make sense, other times where that would be too much noise and you want a reference. Steve Steve I don't think you need all 3 steps. OK. "Then" is awkward 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
