[rspec-users] Constraints / Global requirements

[Matt Wynne]

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.net
http://www.songkick.com