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

Raimond Garcia voodoorai2000 at gmail.com
Mon Nov 9 07:05:32 EST 2009


IMHO steps can test everything that view specs can test,
but in a much faster and will less effort.

You don't have to build a huge feature to test
a complex view, you can just split it into different
scenarios.  In the profile example of a social site,
you could have a scenario for friend, one for personal
info, one for messages in your wall etc, etc. All
nice and clear for developers, designers and business
man.

Regarding the detail of features, I think if that
if someone in the business does not get involved
enough to look at the features and agree on them,
them before starting with the implementation then
we don't have a commitment.  If the president
of the company is too busy, someone else
should be in charge of agreeing on the stories.
We are not talking about implementation details,
we are talking about the behavior of the application.

That said, I think there is a missing interface
in features, where one should be able to reduce
detail or show it.  Just like nesting steps
but not in step files, instead they should be in
the feature file.  For example:

When I fill in the form correctly

Every nested step should be visible in the feature file,
or hidden depending on what the person reading the
feature is most interested in seeing.

Footers and other layout checks, I simply test
them in the main page, I think that covers the
requirement that they will be seen in all pages.

Zack, you example:

  Then I see the top 3 scorers in the leaderboard are:
     | 1 | Bob  |
     | 2 | Mary |
     | 3 | Fred |

Is a very good one.  See the beauty of steps,
is that you don't have to write a single line of
ruby to test this. You can just reuse steps.
For that we would have to re-write this step
to be more reusable, something like this:

Scenario: Top Scores
  Given the following users:
        | name | score |


On Nov 8, 1:55 am, Andrew Premdas <aprem... at gmail.com> wrote:
> 2009/11/5 Chuck van der Linden <sqa... 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-us... 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
> lost.
>
> 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
>
> Feature
> As a user
> I want to have a profile
> So I can stop you spamming me
>
> Scenario
> 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
>
> Andrew
>
> _______________________________________________
> rspec-users mailing list
> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users


More information about the rspec-users mailing list