Cucumber Feature Scenario critique

Andrew P. wrote:

James,

I’d question whether you need to give a monkey’s about ‘entity’. Whilst
it maybe an essential concept in the overall legal framework that doesn’t
mean it has to be in YOUR world. If your software is about recording services
provided to some client and related payments. You can simplify - you can
just choose not to model all that legal stuff. If you model everything
you’ll

I have been mulling this over these past few days. I now think that
what is wrong, besides having as yet only vague ideas of how this is all
meant to work, is that I am injecting too many implementation details
into the features and scenarios. Whether or not a client is a
stand-alone design element or is dependent upon a superior element of
abstraction is really quite beside the point insofar as the presentation
of the system to the user is concerned. I now believe that I should
just be writing down whatever it is that a client has to be in order to
satisfy the business requirements. If we need a higher level of
abstraction to capture other attributes then that should remain
invisible to the users.

Of course, realizing this issue and actually dealing with it are two
different things. I will probably experience a great deal of difficulty
arriving at a balance between expression and implementation.

On Mon, Mar 2, 2009 at 7:31 AM, James B. [email protected]
wrote:

Whether or not a client is a
stand-alone design element or is dependent upon a superior element of
abstraction is really quite beside the point insofar as the presentation
of the system to the user is concerned.

I like to focus on that key word, “presentation,” meaning what a user
sees on a screen or a piece of paper. The only truly important part of
a system is its physical output. Everything else is subservient to
that end.

Define an output (“customer balance on web page”). Define how to make
that happen, via a story/feature. Repeat.

///ark