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

On Sat, Mar 14, 2009 at 10:50 AM, Mark Wilden <mark at mwilden.com>
wrote:
> On Sat, Mar 14, 2009 at 5:59 AM, Matt Wynne <matt 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?

Cheers,
David

David Chelimsky wrote:
> On Sat, Mar 14, 2009 at 10:50 AM, Mark Wilden <mark at mwilden.com>
wrote:
>   
>> On Sat, Mar 14, 2009 at 5:59 AM, Matt Wynne <matt 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"

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-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>

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

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