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

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

On Feb 17, 2009, at 3:27 PM, 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?
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
>
> Thanks,
> -lenny
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

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

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
>

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?




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>

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 Fierer wrote:
> 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?
>
>
>
>
> 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
>
> _______________________________________________
> 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/20090219/5ce3056b/attachment-0001.html>