[rspec-users] Cucumber Feature Scenario critique

James Byrne 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.
> Michael

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 mailing list