David Chelimsky wrote:
On Sat, Mar 14, 2009 at 10:50 AM, Mark Wilden <[email protected]> wrote:
On Sat, Mar 14, 2009 at 5:59 AM, Matt Wynne <[email protected]> wrote:
I'm not sure if I like this - dependency between steps seems like a dodgy
road to go down.
I'm wondering how you'd feel about a style I've adopted:
Scenario: Accepting a direct challenge, without leaving a comment
Given there is a challenge
And I am logged in
One thing I do fairly consistently is put "logged in" steps first.
Given I am logged in as "admin"
And there is a challenge
etc
the /as "admin"/ bit creates a user with login names, passwords and
roles derived from the value.
I also only include these when they are meaningful to the scenario. If
I'm working on a bit of functionality that only "admin" (for example)
can access, I'll have a separate feature talking about access, and
leave that business out of scenarios for this functionality. So
something like:
Scenario: valid vacation request
Given I have accrued 10 days vacation
When I submit a vacation request with:
| start | days |
| next monday | 5 |
...
... would take care of logging in for me implicitly, as being logged
in is a fair assumption for this scenario and is spec'd elsewhere.
Any red flags for ppl? Are you doing it this way? If not, how else?
I have been doing the same thing as you.
However recently I have started using Background [1] more and more when
login is not the main focus of the feature:
Background:
Given I'm logged in as "admin"
Scenario: valid vacation request
Given I have accrued 10 days vacation
When I submit a vacation request with:
| start | days |
| next monday | 5 |
I quite like this as it allows me to minimise login crossover in steps
that require login but don't want to explicitly say so. i.e.
Given I have accrued 10 days vacation
The step definition would having nothing to do with login, which might
save having to check if login has already been done and avoid doing it
again in-order to make the step reusable.
--
Joseph Wilk
http://blog.josephwilk.net
[1] http://wiki.github.com/aslakhellesoy/cucumber/background
Cheers,
David
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
