[Cucumber] Feature vs. Scenario

Testing RSpec
1

I’m curious what other people’s thoughts are about when to use
Features vs. Scenarios and how much it matters. I’m getting the sense
that the line is a thin one, and has more to do with complexity/time
to develop than anything else. I had originally enforced a fairly
rigid definition of ‘Scenario’ to represent a particular
variation(e.g. sufficient funds, insufficient funds), but lately I’ve
been seeing a lot of examples where the scenario is more like a mini-
feature.

ex. Mini-feature style

Feature: Create a new correspondence to an author

Scenario: Caution users about sending ‘questionable’ types of
correspondence

Scenario: Lock manuscript before creating correspondence

These scenarios are each distinct things so to me are ‘features’ in a
way but they may also be trivial to implement, so using any kind of
‘a feature should generally take n days/weeks to implement’ guideline
would make that smell. Also, just because it might be trivial to
implement doesn’t mean that I don’t want to attach some context/
justification for documentation purposes…

ex.

Feature: Create Correspondence / Caution before creating
‘questionable’ types of correspondence
In order to help avoid sending embarrassing letters
Users should be forced to confirm they want to proceed
before being able to create a correspondence deemed ‘Questionable’
by nature of its type
…
Feature: Create Correspondence / Check for locks
In order to prevent invalid information from being sent out
I should not be able to create a new correspondence
when a lock has been placed on the manuscript

It used to be possible to have multiple features per file so feature
vs. scenario could boil down to: Use feature if you want to annotate.
This is no longer the case and I’m not convinced that was a good idea
anyway. I guess that could still be accomplished by organizing
features via directories or maybe tags.

create_correspondence/
caution_questionable.feature
check_locks.feature

Another style related thing I can’t decide on is what my scenarios
should ideally represent.

One style is to use the scenario title as the ‘what’ and the Given/
When/Thens as the proof(acceptance test)

Scenario: Reject when account has insufficient funds
Given I have an account with $10
And I attempt to withdraw $20
Then I should have $10 in my checking account
And I should see ‘Insufficient funds’

Another style is to use the Given/When/Then as the ‘what’

Scenario: Insufficient funds
Given I have an account with $10
And I attempt to withdraw $20
Then I should have $10 in my checking account
And I should see ‘Insufficient funds’

I find myself leaning toward the former most of the time. This was a
bad example(too simple), but I find the latter style tends to blur the
goal a bit.

Thanks
-lenny

2

On Thu, Mar 19, 2009 at 9:44 AM, Lenny M. [email protected] wrote:

These scenarios are each distinct things so to me are ‘features’ in a way
but they may also be trivial to implement, so using any kind of ‘a feature
should generally take n days/weeks to implement’ guideline would make that
smell.

I don’t think there is a correspondence between a feature and its
implementation time. A feature defines a unit of user value. A very
useful feature could be trivial to implement. A minor feature could
take weeks. This is why developers should cost features, not business.

///ark

3

I think writing features is a new art form and as such we just don’t
know
answers to questions like this yet. After a while we might be able to
move
towards a consensus given certain criteria, and people might be able to
come
up with rules of thumb that help (i.e. if its got more than 7 scenarios
create another feature). But ultimately the judgement will be very
subjective and very dependent on context.

As features develop and more scenarios are implemented alot of
refactoring
should be done to

  1. Make sure scenarios are in the ‘right’ feature
  2. To create new features when a feature gets overladen with scenarios
  3. To change the location of a feature in your feature hierarchy so its
    in
    the obvious place

In a similar way step definitions will need refactoring and adjusting.

I can see that a projects features can easily turn into a chaotic mess
if
you don’t keep on top of this.

There is a great advantage in viewing your features as a whole, and
ensuring
this whole is beautiful and describes you application with precision and
clarity. Whilst this will inevitably lenghthen the task of writing
features
when you begin, it will greatly reduce the burden of writing features
when
your project is more mature.

HTH

Andrew

On a related point I think your examples would read better with a when

Scenario: Reject a withdrawl when account has insufficient funds
Given I have an account with $10
When I attempt to withdraw $20
Then I should have $10 in my checking account
And I should see ‘Insufficient funds’

2009/3/19 Lenny M. [email protected]