rspec users - Mar 2009 - [Cucumber] Feature vs. Scenario

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

On Thu, Mar 19, 2009 at 9:44 AM, Lenny Marks <lenny at aps.org> 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

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 Marks <lenny at aps.org>
> 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
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20090319/78aba063/attachment-0001.html>