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
