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...
On Mar 14, 11:32 am, David Chelimsky <[email protected]> wrote:
> On Sat, Mar 14, 2009 at 1:04 PM, Joseph Wilk <[email protected]> wrote:
> > 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"
>
> 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?
>
>
>
>
>
> > 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
>
> _______________________________________________
> 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
