[rspec-users] Constraints / Global requirements

Steve Molitor stevemolitor at gmail.com
Thu Jan 8 11:45:58 EST 2009

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 |
  | "sam at foo.com | valid    |
  | "tom@"            | invalid  |


Then <email> should be a valid email address
  | email                 |
  | sam at foo.com  |
  | tom at 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.


I don't think you need all 3 steps.  OK. "Then" is awkward

On Wed, Jan 7, 2009 at 9:00 PM, Pat Maddox <pergesu at gmail.com> wrote:

> On Wed, Jan 7, 2009 at 6:22 PM, Stephen Eley <sfeley at gmail.com> wrote:
> > On Wed, Jan 7, 2009 at 7:00 PM, Steve Molitor <stevemolitor at 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.maddox at gmail.com".should be_valid_email
> "pat.maddox+foo at gmail.com <pat.maddox%2Bfoo at gmail.com>".should
> be_valid_email
> "pat.maddox at 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.maddox at gmail.com is a valid email address
> pat.maddox at gmail is an invalid email address
> You can achieve this with cucumber already...
> Then pat.maddox at gmail.com is a valid email address
> Then pat.maddox at gmail is an invalid email address
> but it looks stupid.
> Pat
> _______________________________________________
> 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/20090108/b4030233/attachment-0001.html>

More information about the rspec-users mailing list