[rspec-users] [cucumber] Features with multiple user iterations ¿?

Zach Dennis zach.dennis at gmail.com
Wed Jan 21 09:57:17 EST 2009

On Wed, Jan 21, 2009 at 9:35 AM, Joseph Wilk <joe at josephwilk.net> wrote:
> Juanma Cervera wrote:
>> I am specing a feature, maybe at more high level of what it should be,
>> and this makes scenarios that involves more that one rails controller.
>> Is it possible or convenient?
> I do not think its a problem touching multiple controllers if that's what is
> required for the user to achieve some specific value from the system. The
> value is king.

To add this Joseph's comment, a general rule of thumb I follow is that
I don't think about what controllers (if any) my scenarios are going
to use. Since the scenario communicates value and behaviour provided
by the app it's up to me as the developer to determine a good
implementation. This may involve multiple controllers, one controller,
or no controllers.

This doesn't mean that I don't have a general idea of how I'm going to
implement something because I usually do. But that's just because I'm
a developer and as soon as I see a behaviour wanting implementation my
brain goes in problem solving mode and starts to determining possible
paths to a solution. The trick is to not to let this influence how you
write (or encourage customers if you're working with them) scenarios.

Here's a quick example. Let's say that you start by thinking one
controller will suffice so you write your scenario for one controller.
As you implement the scenario you may determine you really want to
have two controllers because it helps keep your controller
implementations clean. At this point you shouldn't have to change your
scenario because you didn't change what the app is doing -- you just
changed how it is doing it. So, changes should be limited to step
definitions and actual implementation and not the scenario text

>> I have scenarios like this (although it's only an unreal example):
>> Feature: Making a reservation for a service.
>>  Scenario: Making the reservation
>>    Given I want to make a reservation for a service
>>    When I choose the service
>>    Then I see the page 'service1/1/options'
>>    When I select option 1
>>    And I click on "submit"
>>    Then I will be asked for a confirmation
>>    When I answer 'Yes'
>>    Then I see "Ok"
>>    And I go to "/services/1"
>>  Is this ok or I should define the features with only one single
>> iteration?
> I find deviating from the ordering of Given/When/Then can sometimes produce
> scenarios that are hard to read and conceptualise. So  I personally avoid
> multiple iterations in a single scenario. This however does not mean you
> should not touch multiple controllers.
> I would suggest perhaps something like this for your example scenario:
> --
>  Scenario: Making a successful reservation for massage service
>   Given I have gone to the reservation page
>   And I selected the service "massage"
>   When I choose the option "extra oil"
>   And I press the "make reservation" button
>   And I confirm my reservation
>   Then I will see "Ok, your reservation has been made for blah. Thanks!"
>   And I will see the total price
>   And I will be redirected to the service.
>     Scenario: Making a reservation but cancelling at confirmation
> --
> My scenario would still fail based on the 'thens' you mention. For example
> if I don't see the page 'service1/1/options' then I can never click the
> option for extra oil. So your thens have become implied. They are part of
> the journey, the destination (and value) is seeing I've made a reservation.
> Looking at your initial steps this one jumps out at me:
>   Given I want to make a reservation for a service
> While it gives intent and a goal it does not explain the start state so I
> would question its usefulness. It feels more like the scenario name.
> --
> Joseph Wilk
> http://blog.josephwilk.net
>> Juanma Cervera.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Zach Dennis

More information about the rspec-users mailing list