2009/1/8 Zach Dennis zach.den...@gmail.com
On Thu, Jan 8, 2009 at 11:32 AM, Steve Molitor stevemoli...@gmail.com
wrote:
I guess that would work.
What would work? You top-posted, any way you can inline post to the
spot you're responding to? Sorry to be an email nazi, but you're
making me
On Tue, Jan 13, 2009 at 4:32 PM, Andrew Premdas aprem...@gmail.com wrote:
2009/1/8 Zach Dennis zach.den...@gmail.com
On Thu, Jan 8, 2009 at 11:32 AM, Steve Molitor stevemoli...@gmail.com
wrote:
I guess that would work.
What would work? You top-posted, any way you can inline post to the
On 14/01/2009, at 09:17 , Zach Dennis wrote:
The only recommendation I have is for people to not remove the portion
of the email they are responding to, and to keep their response close
in approximation to what they are responding to.
A: Because it messes up the order in which people normally
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
I guess that would work. But a method would probably work too, if I'm
understanding correctly (often a bad assumption!). I.e. /(.*) should be
a valid date/ would call valid_date?(date), or something. Anyway, yes that
sounds promising.
Steve
On Wed, Jan 7, 2009 at 8:09 PM, Pat Maddox
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
|
Whoops I misunderstood again. You'd validate that it was an instance
ValidDate to make sure the date validation code was executed. Got it now.
Maybe you could mock out the date validation part of the code and set an
expectation that it should be called:
On Thu, Jan 8, 2009 at 11:32 AM, Steve Molitor stevemoli...@gmail.com wrote:
I guess that would work.
What would work? You top-posted, any way you can inline post to the
spot you're responding to? Sorry to be an email nazi, but you're
making me do all of the work for wanting to hopefully
Sorry. I was responding to this from Pat Maddox:
Another idea I had is to potentially introduce a ValidatedDate class,
and then your should be a valid date step checks that the field is
an instance of ValidatedDate. That has the affect of ensuring that
people use your validation code in
On Wed, Jan 7, 2009 at 9:23 AM, Steve Molitor stevemoli...@gmail.com wrote:
I have two related questions: What is the best way to express global
requirements, and how does one do it in Cucumber. The first question is the
one I'm most interested in right now.
By a global requirement I'm
On 7 Jan 2009, at 17:23, Steve Molitor wrote:
I have two related questions: What is the best way to express
global requirements, and how does one do it in Cucumber. The first
question is the one I'm most interested in right now.
By a global requirement I'm talking about requirements
Pat,
Thanks -- I misunderstood your original response you sent below. For some
reason I read it as 'use rspec specs to validate the date logic' and missed
the bit in the second paragraph where you suggested creating an explicit
date feature. Doh! Sorry for not reading carefully.
This sounds
On Wed, Jan 7, 2009 at 12:23 PM, Steve Molitor stevemoli...@gmail.com wrote:
By a global requirement I'm talking about requirements like 'all emails must
be formatted like this...' Some people call them constraints, but I'm
focusing on UI or business rules, not technical things.
You say must.
Thanks Matt I think you're right. Ironically on a past project customers
wanted a little drying up in the use cases because that helped their flow,
and QA wanted more inline expansion because that helped their testing flow.
The customers wanted to read about the new features, and didn't care to
Perhaps. But I'm not sure then what the difference is between requirements
that should (no pun intended) be expressed via RSpec examples versus
features. Lots of features use the word should in their then clauses.
Take this example from the 'Feature Introduction' of the cucumber wiki:
From a testing perspective it would be nice if cucumber could actually run
the date validation feature everywhere it applies.
Sure, and you can have a step like
Given birth date is valid
Given /(.*) date is valid/ do |field|
TestData.valid_dates.each do |date|
@it.send #{field}_date=,
Yeah I thought of something like that. Actually we do something like that
in one step now that I think about it. But I really wanted to execute the
same exact date feature (for example) doc that the user verified to make
sure nothing got lost in translation. Which I could do if I
Another idea I had is to potentially introduce a ValidatedDate class,
and then your should be a valid date step checks that the field is
an instance of ValidatedDate. That has the affect of ensuring that
people use your validation code in those spots where you want them to.
How does that sound?
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
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
20 matches
Mail list logo
