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' features.
>> 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 articulate.
>> Steve
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 North:
http://dannorth.net/index.php?s=examples+flow
Matt Wynne
http://blog.mattwynne.nethttp://www.songkick.com