[rspec-users] [Cucumber] Level of features / Feature dependent steps

Mischa Fierer f.mischa at gmail.com
Wed Feb 18 11:07:56 EST 2009

Ben has a good post on the declarative vs imperative styles here:

I totally agree with Josh, and indeed wrote out my own version of his login
example before realizing I should probably read his post before replying!

I agree  that each scenario should go into a good amount of detail about
what specifically being tested, rather than letting it be hidden in a step.
If other things have to happen in a scenario that do not involve what is
being specifically tested but must be included for setup, then if it's DRYer
it makes sense to make a more abstract step.

This also gives you a speed boost if done correctly, for example a "given I
am logged in as foo" step can just post to /session or w/e , rather than
going to /login, filling in the form and pressing the button and waiting.

I'm not sure if I would go as far into the dsl as you are in the second
example, though, Lenny. Depending on whether or not you were able to reuse
those steps, as you say, you would over the course of a few months end up
with an entire level of scenario dependent steps.

I might instead start by just using webrat / generic steps as long as you
can, and then taking a look at all your feature files and deciding what you
can dry up / what makes sense to move into a more client specific dsl.

Finally, having been doing cucumber for a while now, I've found that i've
been moving more towards the imperative style, simply because it's faster to
work with.

For example, if it were in the early stages of the app, I might even do
something like

Scenario: I Pay a bill when I have enough $
       Given a checking account
       And the checking account has "$50"
       And a payee named "Acme"
       And an "Acme" bill for "$37"
       When I follow "bills to pay"
       And I follow "Acme"
       And I press "pay bill"
       And I press "confirm"
       Then I should see "payment success"
       When I follow "account summary"
       Then I should see "$13 remaining"
       And I should see "you paid $37 to Acme"

This is pretty ugly, but not out of the question imo.  While it has its
downsides, one benefit is that it encourages a client to actually think
about how the site should work before you make it. For example, they
actually get to think about things like whether there is a payment success
page or not, rather than deciding that there shouldn't be one after you've
spent lots of time building it.


On Wed, Feb 18, 2009 at 7:12 AM, Josh Chisholm <joshuachisholm at gmail.com>wrote:

> I find that the _first_ example of some functionality should be
> imperative (say specifically how to achieve something step by step)
> and subsequent mentions of the same functionality should be more
> declarative (say in abstract terms what to achieve, but spare the step
> by step details). For me, this is consistent with discussing features
> with customers: it starts out step by step, then in subsequent
> conversations (especially after implementation of the imperative
> steps) we can discuss the same thing in more abstract terms.
> An obvious example is login
> # login.feature
> Scenario: Successful login
> Given there is a user 'josh'
> And the user 'josh' has the password 'pass'
> When I visit the login page
> And I enter the username 'josh'
> And I enter the password 'pass'
> And click 'submit'
> Then I should see 'welcome josh'
> # some-other.feature
> Scenario: Something that requires login
> Given I have logged in successfully
> ...
> # login_steps.rb
> Given /I have logged in successfully/ do
>  Given "there is a user 'josh'"
>  Given "the user 'josh' has the password 'pass'"
>  When "I enter the username 'josh'"
>  ...
> end
> There is duplication between the first imperative feature and the
> login steps, but I think that's a slightly different issue from
> "Feature coupled steps". The "Given I have logged in successfully"
> step is not coupled to a particular feature, it is an aggregation of
> other steps. It is designed to be used in different features.
> Going back to your example, I would use the first style. Later, I
> would introduce the aggregate step "Given I have paid a bill with
> sufficient funds" as and when I needed to. Like Jonathan said, there
> is still the issue of shared state, but arguments can be passed
> through the aggregate steps to the imperative steps depending on how
> you feel about this.
> Josh
> On Wed, Feb 18, 2009 at 8:45 AM, Matt Wynne <matt at mattwynne.net> wrote:
> >
> > On 17 Feb 2009, at 20:27, Lenny Marks wrote:
> >
> >> Forgive the long post, just looking for input/advice/alternate
> opinions..
> >>
> >> Like many I think that going through the exercise of framing user
> requests
> >> in Cucumber terms(Features, Scenarios..) really helps facilitate
> necessary
> >> conversations and avoid time wasted implementing the wrong thing(e.g. as
> a
> >> requirement/specification tool). However, I'm a bit confused when it
> comes
> >> to tying this in with Cucumber.  I've come across many suggestions about
> >> audience being king as far as language used in features, but when
> writing
> >> features as part of a specification for a new feature, I consistently
> find
> >> myself writing at a higher level than most any examples I've come
> across(See
> >> example below).
> >>
> >> In the past we've typically relied on very informal means of specifying
> >> new features(Wiki pages, paper, and verbal communication). No that's not
> our
> >> problem..;-) TPI, Even with extensive object level specs, the full
> details
> >> of what an application does and how it is expected to behave from the
> >> outside tends to get lost in the app over time. For example, we have a
> few
> >> applications that were developed by a consulting company. Even
> concentrating
> >> only on the UI and the flow of the application, there are many features
> that
> >> are kind of hidden within the app(ex. assign to drop down that should
> keep
> >> most recently used names first). Without being extremely familiar with
> the
> >> app, all you really know(as a developer or tester) is that it renders
> >> successfully, which is an obvious maintenance problem. Even with newer
> apps,
> >> after a feature is implemented it tends to get lost inside the
> application.
> >>
> >> I was thinking that Cucumber could really work here as a full life cycle
> >> tool because the same artifacts that were initially used to specify a
> >> feature, could be kept and re-used as documentation for users and
> testers.
> >> Unlike alternatives such as keeping a Wiki page up to date, having
> features
> >> linked to implemented steps serves as integration tests and also ensures
> >> that the feature as written, is still accurate/up to date. (Even link
> >> Cucumber output to Wiki page)
> >>
> >> Anyway, reading through Cucumber docs and examples, I almost always see
> >> much more specific examples.
> >>
> >> e.g. (from RSpec book)
> >> Feature: Pay bill on line
> >>
> >> Scenario: Pay a bill
> >>        Given a checking account with $50
> >>        And a payee named Acme
> >>       And an Acme bill for $37
> >>        When I pay the Acme bill
> >>        Then I should have $13 remaining in my checking account
> >>       And the payment of $37 to Acme should be listed in Recent Payments
> >>
> >> That makes sense to me from a testing perspective, but it just doesn't
> >> seem right to me from the perspective I speak of above. If I were
> flushing
> >> out this feature with users, I'd have probably wound up with something
> more
> >> like:
> >>
> >> Scenario: Pay a bill with sufficient funds
> >>        Given I have a bill to pay
> >>        And I have enough money in my checking account to cover it
> >>        When I pay the bill
> >>        Then my checking account should be debited by the amount payed
> >>       And the payment  should be listed in Recent Payments
> >>
> >> One problem is that obviously this way involves always writing an extra
> >> level of feature dependent steps. It just seems to me that the specific
> >> version tends to distract from the actual story. I'm sure I'm looking at
> >> this backwards, but does anyone else use Cucumber similarly?
> >>
> >> Thanks,
> >> -lenny
> >
> > My view is, prefer the latter (abstract) style, use the former (specific)
> > style when you have to for clarity. Each can make sense in the right
> > context, but the latter style is definitely much easier to read.
> >
> > In the end I find you usually need some specific examples to drive out a
> > working system if the feature is at all interesting, but trying to stick
> to
> > the abstract style as long as possible is a good habit to get into.
> >
> > There was a discussion some time ago about calling these two styles
> > 'declarative' and 'imperative'. I'm afraid I'm still too dumb to remember
> > which one is which, but someone else will surely chip in. 'Abstract' and
> > 'Specific' are feeling better to me as I type this.
> >
> > Matt Wynne
> > http://blog.mattwynne.net
> > http://www.songkick.com
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090218/c526f975/attachment-0001.html>

More information about the rspec-users mailing list