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@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
