[rspec-users] Cucumber Feature Scenario critique
lists at technomage.com
Fri Feb 20 13:32:20 EST 2009
I would suggest a different approach to organizing the features. In
particular I would recommend the features be used to test
implementation invariant aspects of the system. Our features are
whole stack sequences that involve views, controllers, and models in
almost every case. We test the "system" not the parts. In the ideal
case you will specify the system up front so little should change from
bug reports unless they are really a change in requirements.
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.
On Feb 20, 2009, at 9:09 AM, James Byrne wrote:
> When I initially began working with cucumber and developing features
> steps from existing code I went through a process (prompted by the
> members of this group) of developing increasingly abstract
> (declarative?) wording for the feature scenario steps. Now, I am
> finally at the stage where I am using features to drive new code. I
> would appreciate very much some advice on how to word a design desire
> into a feature scenario.
> The example I have chosen is that of a client. In our design and
> requirements discussions we have arrived at the idea of "client" being
> that of an ephemeral "role" assigned to a durable "entity". A client
> role is thus conceived as episodic in nature. An entity can be a
> for a period of years, then dormant for a period (whether due to
> in their business patterns or a departure to a competitive service)
> then active again.
> For tax reasons it is important to know precisely when a client was
> active and when they were not. For business reasons it is important
> that dormant accounts be deactivated as soon as this state is detected
> and confirmed. It is however, vital that all previous history of
> activity not be disturbed by any changes in status and that all the
> cumulative history of a single legal entity be kept together.
> The questions I have relate to how best put this down as a set of
> features or scenarios within a feature or features. I am toying with
> idea of a general, application wide, feature file (app.feature) that
> contains the barest statement of what each major component or
> element of
> the evolving application requires. Then, as the step definitions are
> expressed, the detailed features are arranged in hierarchy of files
> according to their anticipated nature (external component, model,
> controller, view, service or library so far).
> So to begin with, at the highest level I think something like this
> Feature: A Web Based Business Application for Transportation and
> In Order To: Conduct Routine Business
> An: Authorized User
> Should: Securely Access the Web Application
> To: Reduce Costs #The work will be done anyway and the price won't
> Scenario: The Application Has Authorized Users
> Scenario: The Application Has Entities
> Scenario: The Application Has Clients
> Given I have a user named "admin"
> And the user named "admin" authenticates
> And the user named "admin" is authorized to "add" "clients"
> When they visit the add new client page
> And they provide valid client data
> And they submit the new client
> Then they should see a new client added message
> The app.feature file will contain no further specifics respecting
> clients. To deal with these specifics I will later create a
> model/clients/client.feature file (or files) that will detail the
> implementation of that model. The step definitions given above will
> into model/clients/step_definitions/client_steps.rb
> I think this approach will work but I really have no experience with
> organizing a large scale project around BDD. Any insight and
> that anyone can provide is greatly appreciated.
> As a supplemental issue: We use a project administration system
> (Redmine). Have any of you adopted practices with respect to the
> relationships between issue tickets and feature scenarios that you
> Posted via http://www.ruby-forum.com/.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users