[rspec-users] Cucumber Feature Scenario critique
apremdas at gmail.com
Mon Feb 23 19:55:48 EST 2009
If this is the case then to do BDD well you have to simulate the dialogue
between customer and developer. At the moment you are so thinking like a
developer so you are starting with detailed technical features rather than
general customer features. Also you're using such complicated language, I
feel you really should make the effort to simplify right now.
One tip that might be useful is to be very clear with your language and find
better names. If you need adverbs and adjectives to clarify your verbs and
nouns, then your verbs and nouns aren't good enough.
Client is not a good name for an emphemeral role. If you need adverbs and
adjectives to clarify your verbs and nouns, then your verbs and nouns aren't
good enough. I'm not convinced that Entity is a particularly good name
either the fact that you need so many words to specify what it is = bad
Now if you use replace Entity with Client, then you have Clients who you
represent. Each client has a history. The history consists of 'periods' when
you represented them (haven't found a good word for that yet) 'term' might
be reasonable but I'm sure there is some proper legal term perhaps related
to contract. Anyhow use whatever resources you can and find single words if
you can or hyphenated words if you really have to
As for your features they can start super simple
Feature: Clients should have a history
Given there is a client
When I view the client
And I select history
I should see the client history
So now you can create your client, rails model with a name field and a
route. Create your history - probably could do this with just a route and a
controller, and a view that says 'history'. Now iterate!
Feature: Client_Histories should have 'terms'
Given there is a client
When I view the client history
I should see terms
Feature: Terms should have starts, ends and one client
Feature: Terms should be made dormant when ...
After each step you implement you think about the language and the sense of
the thing you've just done and quickly review. If it doesn't make sense
If you do this for the core things you have in your applications you will
have something working and visual to then think about things like
authentication and feature organisation which you really want to address
only when you need to.
One of the fundamental ideas about Agile software is that each iteration is
an opportunity for learning, because each iteration gives you feedback. If
you do small iterations then you get back small chunks of feedback which you
can learn from easily. If you do big iterations you get one big chunk of
feedback impossible to fully digest and most likely to be just ignored.
As you are mostly working on your own here you can get started now. Use BDD
to explore your business domain and produce a stupidly primitive
(fundamental? foundational?) features and application, you might just end up
with a firm foundation to build your application on.
Final tip, start with nouns, ignore verbs for as long as possible. e.g think
about 'clients', but don't think about 'adding'. When you've got a whole
bunch of nouns together then you'll have enough context to make working the
verbs much easier.
Seems I've gone on another 'rant'! Thanks for inspiring this James, I've
enjoyed thinking about these things, I can only hope they have some value
2009/2/23 James Byrne <lists at ruby-forum.com>
> Stephen Eley wrote:
> > ...So that's my reality. Cucumber for collaboration isn't the value
> > for me. I suspect that there are a *lot* of companies out there with
> > one-person IT departments that may fit into my situation, and
> > certainly a whole ton of personal projects where there was never any
> > money or 'business case' in the first place. In those cases,
> > communicating features to "the customer" is just talking to oneself.
> > It may still have value, but it isn't about teamwork.
> > Anybody else in a situation like this?
> In essence that describes my situation. The difference being that I do
> have a user (one) who will sit down and work through a feature (the
> first time and then only briefly). There are others who get to comment,
> particularly on issues of nomenclature, but none that have the time and
> inclination to make the sort of effort taken for granted in BDD.
> I see cucumber as way to document my intentions and use the scenarios as
> discussion points with others in my firm. The great advantage is that I
> can then use cucumber to drive what I call testing which, in turn,
> drives coding. The resources do not exist to support much more than
> Posted via http://www.ruby-forum.com/.
> rspec-users mailing list
> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users