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