[rspec-users] Cucumber Feature Scenario critique
lists at ruby-forum.com
Fri Feb 20 15:46:22 EST 2009
Michael Latta wrote:
> I would suggest a different approach to organizing the features.
> Requirements changes have a different workflow than implementation
> bugs. I would recommend you track that difference in your project
> management system. Keep an eye on how much changes after
> implementation to measure how good your requirements capture has been.
This is probably another case where I simply have not yet established in
myself a sensible mental framework for working with BDD. Bear with me
as I struggle through this adjustment.
My apprehension so far is that features are intended to drive out the
design requirements by explicitly stating concrete examples of what the
client considers desirable. The idea of a contract between developer
and client arises from the mutual agreement on functional expression as
given in the feature scenarios.
Definition steps, on the other hand, are the purview of the
design/development team. They can take any reasonable form so long as
1. test the functionality of the implementation in a meaningful way
2. meet the requirements of the scenario
Unit tests are the purview of the implementers and are tied to their
respective code modules.
My concern arises from a desire to establish how I should organize the
features in relation to one another. Given my understanding respecting
features I proceeded from the belief that one could arbitrarily start
anywhere in the system design. Features would allow one to elaborate
both up and down in detail as appropriate for the stage of the project
and the area of immediate concern.
As a practical matter it appears to me that the logical flow is
Authentication/Authorization, administrative functions relating to
record maintenance, algorithmic user applications, report generation,
utilities, and finally loose ends. The application can be sliced so
that all or most of these issues are dealt with within one specific
aspect before tackling another.
We are using Redmine to administer the project so milestones, issue
tracking and such are kept in there. However, I have acquired this
notion of functional decomposition relating to features. As i see it
the basic gross requirements of the system (there will be clients, there
will be invoices, etc.) are expressed as scenarios in a feature file
somewhere. Then as more detail is driven out more features are inserted
into the composition tree as appropriate.
Is this completely at odds with what I should be doing?
Posted via http://www.ruby-forum.com/.
More information about the rspec-users