[rspec-users] Cucumber Feature Scenario critique

Andrew Premdas apremdas at gmail.com
Mon Feb 23 10:57:50 EST 2009


Personally I think your missing the point entirely about BDD. The
fundamental idea of BDD is to drive/guide the relationship between the
customer and developer. So you shouldn't be having meetings with customers
that arrive with

" the idea of "client" being that of an ephemeral "role" assigned to a
durable "entity"

Instead you should have meetings with customers that end up with written

There is no way I would expect any customer I've ever worked with to

" the idea of "client" being that of an ephemeral "role" assigned to a
durable "entity"

nor would I expect any developer I've ever worked with to turn this into
meaningful code. And if that process was completed I'm quite sure the
chances of the code meeting the customer expectation would be zero.

Having up front requirements meetings that produce that sort of language,
and then having you work afterwards work on top of that to produce features
is just silly. Agile tools don't work with this approach.

I'm speculating wildly here, but it seems to me in your organisation you are
trying really hard to get your development side into cucumber features and
automated testing which is admirable, but the focus is completely in the
wrong place. The focus has to first be about getting your customer really
into producing features with you. If you achieve that then what should
happen is

1. You and your custoimer meet often and work (rather than just talk)
together and produce features
2. Your customer prioritizes the features
3. You give your developers the features and say implement this
4. When the features pass the customer reviews things

Iterate that a few thousand times and you might end up with a pretty good

If your present your developers with well written features and the
cukes.info link and the mailing list link, and a bit of your time to get
them up to speed, then they really should have no problem embracing
cucumber. I mean how many developers have ever been given clear instructions
(that can easily be executed as acceptance test) about what to do, from
anyone never mind directly from the customer!

Finally as far as feature organisation is concerned it really does not
matter at the moment. The important thing is to write and then implement
good features and do it now, because your first ones won't be very good, and
you won't learn to write better ones until you've iterated and produced
something. The features will find a place as you write them and you will
probably have to change the structure and organisation of them many times in
the project if you wish them to tell a clear story with that structure, but
don't worry about that now - you've got enough to worry about.

Dan North's original BDD pages address much of the stuff involved in
actually writing features, and there was an IRC log with Aslak on here which
I thought was very insightful about the dialogue involved in producing a

All best


n.b. I'm expressing my opinions forcefully without much regard to tact or
diplomacy. No offense in any way is intended :)

2009/2/20 James Byrne <lists at ruby-forum.com>

> 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090223/ee3cef2d/attachment.html>

More information about the rspec-users mailing list