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.
Michael
On Feb 20, 2009, at 9:09 AM, James Byrne wrote:
When I initially began working with cucumber and developing features
and
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
client
for a period of years, then dormant for a period (whether due to
change
in their business patterns or a departure to a competitive service)
and
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
the
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
might
serve:
app.feature
Feature: A Web Based Business Application for Transportation and
Customs
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
change
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
go
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
experience
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
found
useful?
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
