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

Lenny Marks lenny at aps.org
Tue Feb 17 15:27:27 EST 2009

Forgive the long post, just looking for input/advice/alternate  

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  

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  

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  

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?


More information about the rspec-users mailing list