[rspec-users] [Cucumber] When do you log in? (was- Adding a step definition)

wolfmanjm wolfmanjm at gmail.com
Sat Mar 14 17:10:47 EDT 2009


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 <dchelim... at gmail.com> wrote:
> On Sat, Mar 14, 2009 at 1:04 PM, Joseph Wilk <j... at josephwilk.net> wrote:
> > David Chelimsky wrote:
>
> >> On Sat, Mar 14, 2009 at 10:50 AM, Mark Wilden <m... at mwilden.com> wrote:
>
> >>> On Sat, Mar 14, 2009 at 5:59 AM, Matt Wynne <m... at mattwynne.net> 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
> >> rspec-us... at rubyforge.org
> >>http://rubyforge.org/mailman/listinfo/rspec-users
>
> > _______________________________________________
> > rspec-users mailing list
> > rspec-us... at rubyforge.org
> >http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users


More information about the rspec-users mailing list