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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
