On Sat, Mar 14, 2009 at 10:50 AM, Mark W. [email protected] wrote:
On Sat, Mar 14, 2009 at 5:59 AM, Matt W. [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?
Cheers,
David
David C. wrote:
Scenario: Accepting a direct challenge, without leaving a comment
the /as “admin”/ bit creates a user with login names, passwords and
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 W.
[1] http://wiki.github.com/aslakhellesoy/cucumber/background
On Sat, Mar 14, 2009 at 1:04 PM, Joseph W. [email protected] wrote:
dodgy
One thing I do fairly consistently is put “logged in” steps first.
can access, I’ll have a separate feature talking about access, and
… would take care of logging in for me implicitly, as being logged
Background:
Given I’m logged in as “admin”
To be completely honest, I had not looked at background yet. Might be
late in the game, but if Background is a collection of givens, then
I’d like to see it not require the Given keyword:
Background:
I am logged in as “admin”
Scenario: …
Thoughts? Too late? Too complex?
I use something similar, however as I need to have my database pre
populated with valid user accounts (the dreaded fixtures) I use
something like…
Given the following users are logged in:
|user|
|first|
|second|
|third|
When the first user sends a message to the second user
Then the second user gets a message from the first user
And the third user does not get a message from the first user
I hide the actual login and the actual login names deep within a
helper class (do_login), and I map the first, second, third users to
the real login names that were created by a fixture or other fixture-
like method in the helper close to where the database gets populated.
So the steps look like…
Given /^the following users are logged in:$/ do |users|
ua= users.rows.collect { |u| u.first }
do_logins(ua)
end
Given /^a (first|second|third) user is logged in$/ do |user|
do_login(user)
end
When /^the (first|second|third) user sends a message to the (first|
second|third) user$/ do |user1,user2|
send_message(user1, user2, “a message”)
end
Then /^the (first|second|third) user gets a message from the (first|
second|third) user$/ do |user1, user2|
check user1 gets “a message” from user2
end
In the helpers…
Aliases= {‘first’ => “FeatureTester1”, ‘second’ => “FeatureTester2”,
‘third’ => “FeatureTester3”}
def do_login(user)
login(Aliases[user], password)
end
etc…