[cucumber] before/after scenarios


#1

Hi Guys,

Sorry for the double-whine but I’ve seen references to these listeners
but not a lot of luck finding any details.

So…that’s it: Setup/Teardown Before/After scenarios…what’s the
scoop?

Thanks,

Tim
(Also, the logo’s are looking awesome!)


#2

On Wed, Dec 17, 2008 at 3:14 PM, Tim W. removed_email_address@domain.invalid wrote:

Hi Guys,

Sorry for the double-whine but I’ve seen references to these listeners
but not a lot of luck finding any details.

So…that’s it: Setup/Teardown Before/After scenarios…what’s the scoop?

That’s it.


#3

Tim W. wrote:

Hi Guys,

Sorry for the double-whine but I’ve seen references to these listeners
but not a lot of luck finding any details.

So…that’s it: Setup/Teardown Before/After scenarios…what’s the scoop?

http://github.com/aslakhellesoy/cucumber/wikis/hooks

Does the information here answer your questions or do you think its
missing some details?

HTH

Joseph W.
http://blog.josephwilk.net


#4

Joseph,

This is very, very helpful and gets me to a place where I can try it.
If anything, I just didn’t think to look in “hooks” for the concept of
setup/teardown. Really looking forward to the book!

Many sincere thanks, I hope i can return the favor some day.

Tim


#5

Tim W. wrote:

(Also, the logo’s are looking awesome!)


rspec-users mailing list
removed_email_address@domain.invalid
http://rubyforge.org/mailman/listinfo/rspec-users

Hey Tim,
The ‘Hooks’ and "RSpec Stories Migration’ pages on the wiki has some
information on this. Have you looked at those pages?

If you have and are still confused, could you be more specific on what
you are needing to do?

-Ben


#6

Joseph W.-4 wrote:

Tim W. wrote:

So…that’s it: Setup/Teardown Before/After scenarios…what’s the scoop?

http://github.com/aslakhellesoy/cucumber/wikis/hooks

Does the information here answer your questions or do you think its
missing some details?

I’ve been thinking there is a good deal of utility to having a “Before”
block at the top of a Feature – for two reasons:

  1. It’s more DRY
  2. It captures the relevant information in a place that’s obvious and
    easy
    to refer to/update

I could achieve goal (1) by simply adding a Before block to a steps
file,
but this would obscure the setup (against goal 2). It also prevents use
of
feature tables in re-using steps, although I think that a short-term
objection since it will probably be fixed some day.

For an example, here is an excerpt of what I would like to set up in
“Venue” feature file:

Feature: Create and Update Venues In order to manage venues An appropriately authorized user Should be able to view, create, edit, and update venues

Before
Given a venue manager role
And the following users:
| username | roles |
| manager | venue_manager |
| owner | |
| basic | |
And the following venues:
| name | verified | creator |
| public | true | |
| public_owned | true | owner |
| unverified | false | owner |

Scenario Outline: Only manager can view verified venues
Given I am logged in as “”
When I visit the show venue page for “”
Then the result should be “”
Examples:
| user | venue | result |
| manager | public | ok |
| manager | public_owned | ok |
| owner | public | not_found |
| owner | public_owned | not_found |
| basic | public | not_found |
| basic | public_owned | not_found |

Scenario Outline: Only manager and creator can view unverified venues
Given I am logged in as “”
When I visit the show venue page for “”
Then the result should be “”
Examples:
| user | venue | result |
| manager | unverified | ok |
| owner | unverified | ok |
| basic | unverified | not_found |



So of course I could make a lump step “set up the venues” but there is
damage done to ease-of-comprehension and maintenance. I can also see
adding
a global Before, but really I don’t want to contaminate other features
with
this particular venue setup (and it will be out of plain sight, which I
don’t want either).

I am still new to BDD so please holler if I’m missing something
fundamental.

-Paul


View this message in context:
http://www.nabble.com/-cucumber--before-after-scenarios-tp21061651p21304997.html
Sent from the rspec-users mailing list archive at Nabble.com.


#7

On 6 Jan 2009, at 05:22, Paul Covell wrote:

Does the information here answer your questions or do you think its
missing some details?

I’ve been thinking there is a good deal of utility to having a
“Before”
block at the top of a Feature – for two reasons:

  1. It’s more DRY
  2. It captures the relevant information in a place that’s obvious
    and easy
    to refer to/update

You might want to check out this ticket, I think you and Eric Kidd
basically want the same thing:
http://rspec.lighthouseapp.com/projects/16211/tickets/153-add-optional-background-section-to-features

Matt W.
http://blog.mattwynne.net
http://www.songkick.com


#8

Paul Covell wrote:

I’ve been thinking there is a good deal of utility to having a “Before”
block at the top of a Feature – for two reasons:

  1. It’s more DRY
  2. It captures the relevant information in a place that’s obvious and easy
    to refer to/update

Looks like the addition of ‘Background’ to Cucumber will solve your
issue.

http://rspec.lighthouseapp.com/projects/16211/tickets/153-add-optional-background-section-to-features#ticket-153-9

WDYT?

I could achieve goal (1) by simply adding a Before block to a steps file,
but this would obscure the setup (against goal 2). It also prevents use of
feature tables in re-using steps, although I think that a short-term
objection since it will probably be fixed some day.

http://rspec.lighthouseapp.com/projects/16211/tickets/121-handling-step-tables-within-scenarios-with-tables-scenario-outline

Its been fixed on the AST branch of cucumber though this is still a dev
branch. At some point it will be merged back into Cucumber.

If there is a pressing need for this is in mainline now shout at me.


Joseph W.
http://blog.josephwilk.net

Given a venue manager role

| basic      | public       | not_found |
| basic      | unverified   | not_found |

I am still new to BDD so please holler if I’m missing something fundamental.