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

Matt Wynne
2009-02-18T08:45:50Z

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