[Cucumber] Level of features / Feature dependent steps

Testing RSpec
1

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…:wink: 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

2

On Feb 17, 2009, at 3:27 PM, Lenny M. wrote:

features as part of a specification for a new feature, I
concentrating only on the UI and the flow of the application, there
users and testers. Unlike alternatives such as keeping a Wiki page
Scenario: Pay a bill
I were flushing out this feature with users, I’d have probably
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?

Not sure about your ‘life cycle’ discussion, but wrt the examples, I
do that all the time.

You’ve probably seen earlier discussions about instance variables.
Some have advised against it, but I use them. Its manageable if
you’re consistent.

eg @account == ‘a checking account’, ‘my checking account’, etc
@bill == ‘the bill’, etc
@bill.amount == ‘the amount’, ‘the payment’, etc
etc

And have default setups
but also more specific ones as needed,

Given /^I have a bill to pay$/ do
@bill = Bill.create( :company => ‘Acme’, :amount => 37 )
end

Given /^I have a bill to pay to “(.+)” for $(\d+)$/ |who, amount|
@bill = Bill.create( :company => who, :amount => amount )
end

so you can have
Given I have a bill to pay
or
Given I have a bill to pay to “Acme” for $37

I’d probably change your 2nd step to

And I have enough money in my checking account to cover the bill

so “my checking account” and “the bill” reference @account and @bill

If you’re managing both checking and savings accounts, i might have
@checking and @savings instead of @account, and make the account type
another argument, and so on

–linoj

3

On 17 Feb 2009, at 20:27, Lenny M. wrote:

features as part of a specification for a new feature, I
concentrating only on the UI and the flow of the application, there
users and testers. Unlike alternatives such as keeping a Wiki page
Scenario: Pay a bill
were flushing out this feature with users, I’d have probably wound
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 W.
http://blog.mattwynne.net

4

Ben has a good post on the declarative vs imperative styles here:
http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/

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.

wdyt?

5

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

6

Just wanted to thank everyone for their replies. I actually recall
that thread now about imperative vs. declarative. I’ve just re-read
Ben’s post along with some of the linked content off the post and now
and I feel a bit more comfortable with the direction I was going in. I
personally tend to favor the declarative style. At least for my
current projects, Cucumber/SDD seems most attractive as a tool that
encourages us to write user stories so that we code the right stuff
and then allows us to turn those stories into executable documentation
that also tests the full stack sanity of our app. I can definitely see
using more specifics in the steps to lessen the burden of writing so
many customized steps, at least when they don’t distract much from the
goal of the story. Recently I was writing a feature for an application
for sending very business logic connected correspondences. If I have a
scenario that applies to all correspondences and I see a step such as
“Given I am sending a ‘CTA’” as opposed “Given I am sending a
correspondence”, then I think it’s kind of distracting.

One thing I came across in the
http://goruco2008.confreaks.com/01_helmkamp.html
screencast was the concept of using verbs in scenario titles(e.g.
reject duplicate names). Up until now I think I had been taking my
translation of ‘scenario’ a bit too literal and using the scenario
titles only state what makes the scenario different and not what the
expected behavior should be(e.g reject duplicates). I’m not sure what
I think about it yet, but stating the expected behavior in the
scenario title and using the steps to demonstrate it can potentially
make things less ambiguous when specifics are plugged in. I guess that
just sounds more like a feature(sub-feature) to me, but I the line
seems pretty blurry and I think has more to do with feature size. I’m
curious how others use scenario titles but that may be worth another
thread.

Anyway, I think the imperative style lends itself more to developers
thinking from the testing perspective(does every field on my
registration make it into the system) while the declarative style is
better suited as customer facing stories. Very subjective stuff, but
for us, I see a lot of value having the executable
documentation(accurate and up to date) that gives reasonable assurance
on sanity but also documents(without a lot of noise) what’s in the
app. What a developer/tester needs to click through and what they
should expect to see, should that need to be done(after refactoring a
bunch of javascript or stylesheets or whatever).

-lenny

On Feb 18, 2009, at 8:07 AM, Mischa F. wrote:

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.

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.