James, 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 features! There is no way I would expect any customer I've ever worked with to comprehend " 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 system 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 feature. All best Andrew 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 <li...@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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
