Forum: RSpec [Cucumber] When do you log in? (was- Adding a step definition)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
David C. (Guest)
on 2009-03-14 18:57
(Received via mailing list)
On Sat, Mar 14, 2009 at 10:50 AM, Mark W. <removed_email_address@domain.invalid> 
wrote:
> On Sat, Mar 14, 2009 at 5:59 AM, Matt W. <removed_email_address@domain.invalid> 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
Joseph W. (Guest)
on 2009-03-14 20:28
(Received via mailing list)
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.
http://blog.josephwilk.net

[1] http://wiki.github.com/aslakhellesoy/cucumber/background
David C. (Guest)
on 2009-03-14 20:39
(Received via mailing list)
On Sat, Mar 14, 2009 at 1:04 PM, Joseph W. 
<removed_email_address@domain.invalid> 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?
wolfmanjm (Guest)
on 2009-03-14 23:30
(Received via mailing list)
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...
This topic is locked and can not be replied to.