[rspec-users] [BDD] View specs and cucumber -- duplication of effort?

Andrew Premdas apremdas at gmail.com
Sat Nov 7 19:55:59 EST 2009

2009/11/5 Chuck van der Linden <sqapro at gmail.com>

> On Nov 4, 5:30 pm, David Chelimsky <dchelim... at gmail.com> wrote:
> > On Wed, Nov 4, 2009 at 3:36 PM, Stephen Eley <sfe... at gmail.com> wrote:
> > > On Wed, Nov 4, 2009 at 3:24 PM, Andrew Premdas <aprem... at gmail.com>
> wrote:
> >
> > > > Personally I now think nested steps are evil - but thats another
> story :)
> >
> > > It sounds like an entertaining one.  I'd love to hear why sometime.
> > > (Though whether the right place for it would be here or the Cucumber
> > > list, I couldn't say.)
> >
> > I'll pipe in since it's here on this list at the moment:
> >
> > I won't go as far as to say that nested steps are evil, but I don't
> really
> > like to use them myself because they do conflate two levels of
> abstraction.
> > I'd sooner have two steps delegate to a helper than one step delegate to
> > another.
> >
> > FWIW,
> > David
> >
> I'll chime in also as to why I really dislike burying details like
> that in the steps file.  Nobody but dev plays around with the lower
> layers and the step files in particular.  Potentially everyone in the
> business may have a hand in the 'feature' definition, or maybe need to
> see or modify it at a later time.  Also a Dev or tester reviewing
> things to see 'how should it work' gets everything high level in one
> place (the feature file) instead of having to chase down into multple
> levels of step files ( an exercise reminding one of why we hate
> spaghetti code) to find the details that matter up at the UI or
> potentially integration test level.
> Remember Rspec/Cucumber are all about implementing BDD..  Part of BDD
> is that more than just the folks in Dev will be looking at what's done
> at the 'feature' level.   If you bury the details of something inside
> the step file, then nobody outside of dev can play along, and that
> defeats a large part of the purpose of BDD.
> If it is important to the business that a particular field be on that
> page, then you ought to have it expressed in the feature and not
> buried in the steps.   Consider something like
> 'Scenario: User reviews their profile details'
> Given I am logged in as: <user>
> When I click the link: view profile
> Then I should see my profile details.
> How much more value to the business (and clarity to those implementing
> the feature) is created if we were to instead have something more
> like:
> ....
> Then I will be on the page: User Profile
> and I will see <field1> identified as <field1label> containing
> <value1>
> and I will see <field2> identified as <field2label> containing
> <value2>
>  etc
> The <> items could either of course be spelled out, or they could be
> parameters in a scenario outline's examples section.
> --Chuck
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Couldn't agree less :-) , although alot of that depends on the business.
There are many problems with the sort of scenarios you prefer

1) They are very fragile - change a label and it breaks. A business will
review the application not the feature. When I change the label who fixes
the feature, and why should I have to run 30 minutes of features to change
one label!

2) You have to get detail correct before you know the context. As a business
person how do I know what details should be in the user profile.

3) It places the responsibility for trivial and obvious decisions with the
business people. And makes them make these decisions before they are ready.
Its much easier to decide what should be on the profile page when you can
see it and navigate to it. And as a business it is cheaper and far more
effective to trust your development team rather than micro-manage them to
the nth degree.

4) With an application of any size the amount of detail these type of
scenarios generates soon removes and chance of the business actually reading
or reviewing the features. Any chance of getting an overview of what the
application does, or even readable reports of what works and what doesn't is

Dev's and testers are perfectly capable of looking at step definitions and
working with them. Business people (at least the ones I know and have
experienced) are much better at telling you want they want by providing
feedback from the application itself than by doing any sort of up front
work. One of the elegant parts of BDD is that by writing simple succinct
features business can get you quickly into a feedback loop. It is much
easier to create

As a user
I want to have a profile
So I can stop you spamming me

When I view my profile
I should be able to stop you spamming me

and start iterating around that, than to create some big feature that
specifies different labels for mailings and whether to use radio button or
checkboxes. It is also much easier for the business to come back to a 5 line
profile feature, and review this by looking at the application, than to
review a 200 line profile feature. This is an Agile process we're supposed
to be working with after all.

All best

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20091108/acfe77bb/attachment.html>

More information about the rspec-users mailing list