Balint Erdi wrote:
Hey Ben, thanks a lot.
The problem I am experiencing now is that information stored in the
session does not seem to be retained between steps (again, only in the
case of selenium sessions, plain sesssion work fine). So the login
function works fine now but when I go to another page afterwards it
throws a big error because the action tries to render something based on
the current user.
Is the session store I am using relevant? I used the default
cookie-based storage and then tried to change to the active-record based
one to no avail. My config is at http://gist.github.com/83635
Thank you,
Balint
Ok, I think I have the problem and it has nothing to do with session
storage. I intend to explain it below so others might benefit from it.
Scenario: Successfully sharing album with group via the "Share with
group" link
Given I am logged in as "pepito"
When I go to my photosets page
I used some existing step definitions I wrote for non-selenium features
to log in the user like so:
Given /^I log in as "(.*)"$/ do |login_name|
@user = User.find_by_login(login_name)
post "/session", :login => @user.login, :password => 'secret' # !!!
end
Given /^I am logged in as "(.*)"$/ do |login_name|
Given %(the user "#{login_name}" exists)
Given %(the user "#{login_name}" is active)
Given %(I log in as "#{login_name}")
end
When the feature gets to "When I go to my photosets page", the selenium
browser is launched but there is no user logged in here, there is no
session, so that step will fail miserably. That's because the line
denoted by !!! does not log in the user in the selenium session but in
the "test session" (I know this is not the proper definition but I
cannot precisely name it).
So if I need a logged in user in a selenium feature I should go the
"hard way" and start from scratch:
Given the user "pepito" exists
And the user "pepito" is active
When I go to the login page
And I fill in "login" with "pepito"
And I fill in "password" with "secret"
And I press "entrar"
And I go to my photosets page
...
It takes some time to get one's head around realizing there is a test
world and a selenium world and keep in mind which action modifies which
world and learn how they can interact with each other (through the
database I guess if they use the same environment).
Please correct me if I am wrong in anything I say above,
Balint
Yep.. that is what I thought was happening. The "test session" is rails
integration session that webrat uses.
I would still use your login step but just have it hit the form. So
something like:
Given /^I log in as "(.*)"$/ do |login_name|
@user = User.find_by_login(login_name)
vist "/session"
fill_in "login", :with => login_name
fill_in "password", :with => 'secret'
click_button "entrar"
end
With that step definition you don't need to pollute all of your features
with the steps to login. As it turns out you can have the best of both
worlds. Meaning, if you want webrat to use the faster post method only
for non-selenium runs you can. Like so:
Given /^I log in as "(.*)"$/ do |login_name|
@user = User.find_by_login(login_name)
webrat.atutomate do
vist "/session"
fill_in "login", :with => login_name
fill_in "password", :with => 'secret'
click_button "entrar"
end
webrat.simulate do
post "/session", :login => @user.login, :password => 'secret'
end
end
In short, the webrat#automate block is only executed with an adapter
that is automating a real browser. Likewise the webrat#simulate block
is only executed when the adapter is simulating a browser, such as the
rails adapter. Does that make sense?
-Ben
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
