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!)
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!)
On Wed, Dec 17, 2008 at 3:14 PM, Tim W. [email protected] 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.
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?
Does the information here answer your questions or do you think its
missing some details?
Joseph W.
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
Tim W. wrote:
(Also, the logo’s are looking awesome!)
rspec-users mailing list
[email protected]
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
Joseph W.-4 wrote:
Tim W. wrote:
So…that’s it: Setup/Teardown Before/After scenarios…what’s the scoop?
GitHub: Let’s build from here · GitHub
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:
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.
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:
- It’s more DRY
- 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
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:
- It’s more DRY
- 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.
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.
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.
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs