Stories with selenium and the db

Testing RSpec
1

Hi all

Tonight I wanted to test out selenium in a story to test some ajax
stuff on a page.

After struggling for an hour or two with disappearing database objects
I found the solution in a blog post by Kerry B…

with the comment included it reads:

Don’t add an ActiveRecordSafetyListener, or it’ll roll stuff back

class Spec::Story::runner::ScenarioRunner
def initialize
@listeners = []
end
end

(the above code belongs in the story helper file, or more specific,
for me in my selenium helper file as not every story uses selenium)

Ok, that worked, but I don’t understand why. Can someone explain what
the big difference is with normal stories and can’t it be solved in a
more cleaner way?

That said, it’s actually very easy to use selenium in a story. Just in
case someone is searching:

  1. Add this in the helper file for selenium stories:

####################
class Spec::Story::runner::ScenarioRunner
def initialize
@listeners = []
end
end

require ‘vendor/plugins/selenium-ruby-client-driver/selenium’

$s = Selenium::SeleniumDriver.new(“localhost”, 4444, “*firefox”,
"http://localhost:3000
", 10000);
$s.start

####################

  1. download the selenium ruby driver, place it in vendor/plugins/
    selenium-ruby-client-driver
  2. start the selenium server (java -jar selenium-server.jar)
  3. start the script/server in test environment

That’s it, in stories you can now use things like: $s.open(“/orders”)

-gr
Ivo

2

On 20 Mar 2008, at 22:58, Ivo D. wrote:

Don’t add an ActiveRecordSafetyListener, or it’ll roll stuff back

the big difference is with normal stories and can’t it be solved in a
more cleaner way?

With specs and Rails Stories, the application is running in the same
process as the specs. With selenium remote control (I assume this is
what you are using throughout), the specs sending requests to the
selenium RC server, which is sending the requests to a different
process. Therefore, if you create the models in a transaction in the
spec process, they will be invisible to the app process (unless you
work read-uncommitted…)

This one bit me too, I lost a day scratching my head.

end
I just commented out the line that includes Rails Stories from
helper.rb. It’s not needed at all with Selenium.

require ‘vendor/plugins/selenium-ruby-client-driver/selenium’

$s = Selenium::SeleniumDriver.new(“localhost”, 4444, “*firefox”, "http://localhost:3000
", 10000);
$s.start

####################

  1. download the selenium ruby driver, place it in vendor/plugins/
    selenium-ruby-client-driver

There’s also a nice gem you can get with (note the capitalisation)

gem install Selenium

Then you can do step 3 as just
% selenium

  1. start the selenium server (java -jar selenium-server.jar)
  2. start the script/server in test environment

That’s it, in stories you can now use things like: $s.open(“/orders”)

I’ve been working on something pretty similar for a client. This is
what I’ve made work so far:

  • browser session per story run, for some isolation (uses a custom
    listener)
  • browser window stays open on failed scenarios
  • auto reset database before scenarios (uses the listener again)
  • a much neater syntax for the selenium ruby driver, such as (OTTOMH)
    browser.username_text_field.type(“fred”)
    browser.submit_button.click
    browser.should land_on_page(“/home”) # works with redirects

I’m pretty sure they will let me open source all the code when the
project is complete. Unfortunately it’s a bit of a hectic right now
but hopefully in the second half of May I’ll get chance to bundle it
up and push it back to the community. It’s a bit frustrating not
being able to do that now, but at least it means by then my selenium-
story runner bridge will have been bashed through a decent sized app
by (if everyone uses it) four developers.

Ashley