[rspec-users] Constraints / Global requirements
stevemolitor at gmail.com
Wed Jan 7 17:37:00 EST 2009
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 see
a regurgitation of all the previously explained features that applied. A
reference or reminder note was just fine.
But anyway, yes focus on clarity and flow for the reader. Sometimes that
will mean getting a little DRYer, in other cases it would me getting a
On Wed, Jan 7, 2009 at 2:46 PM, Matt Wynne <matt at mattwynne.net> wrote:
> 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 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. I can think of two
>> approaches: put the global constraints in one place and reference these
>> features in other features. The other point of view is that no, we want to
>> see these rules in every feature that uses them, so we (customers, BAs,
>> developers, testers) can see everything in one place. For example I can
>> reference the different valid and invalid email scenarios in both the 'add
>> new patient' and the 'add new doctor' features. Or I can copy and paste the
>> email scenarios directly into the 'add new patient' and the 'add new doctor'
>> As a DRY infected developer I prefer the first approach. However I have
>> not found a simple way to have one cucumber feature reference or 'include'
>> another, and have both features get executed. Perhaps partially for that
>> reason, other people on my project want to use the second approach as it
>> seems more straight forward.
>> I realize I can reuse steps. But I want to reference the actual feature
>> in another. To pick a more important example, in my past life I worked on a
>> big leasing application with lots of formulas: to compute the cost of a
>> lease, the cost of fuel cards, the cost of different levels of insurance,
>> etc. I'm going to simply a lot, but say the formula for computing the sales
>> tax is 'subtotal + subtotal * 0.5'. Calculating the sales tax is one
>> feature. Two other features are 'compute lease cost' and 'compute fuel card
>> cost'. They both need to add sales tax. This was before cumber and
>> stories, but some of us preferred the specifications to look like this:
>> LEASE COST FORMULA:
>> a + b + sales tax.
>> Others, especially the testers, preferred:
>> a + b + (a + b * 0.5)
>> In real life the sales (and use) tax calculation was quite complex and
>> changed. When it changed this broke many manual test plan and invalidated
>> many use cases. If we were using cucumber with the second approach it would
>> break many features.
>> Sorry for rambling on so long but I've found this is a hard question to
> I think you might need to try and let go of the idea that your Cucumber
> acceptance tests should be a *complete specification* and instead focus on
> making sure that there is *just enough* specification so that you can be
> sure to be alerted by the tests if something is wrong. Any more is likely to
> do more harm than good.
> I noticed you called yourself a 'DRY infected developer'. Duplication is
> undoubtedly the root of all evil in production code, but there are times
> when it pays to allow a little slack in. Check out this article from Dan
> Matt Wynne
> rspec-users mailing list
> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users