Page Objectt design with Selenium Watir-Webdriver

Hi,

I’m a newbie in both Ruby and Selenium watir-webdriver and want to ask
you if you think below is a good design for my automation test?

  1. I start my test through init.rb
  2. In guide.rb i initialize @driver and let the user pick which tests he
    wants to run
  3. Then i have placed the test for the “start page” in the class
    startpage.rb (i think thats what they mean with Page Object design?)

init.rb
require ‘guide’
guide = Guide.new
guide.launch!

guide.rb
require ‘watir-webdriver’
class Guide

def initialize
@driver = Watir::Browser.new :firefox
end

def launch!
@driver.gotohttp://google.com
get_action
do_action #returning method: verify_elements_present
end

def get_action
#Get user input for the tests i want to run
end

def do_action
#Start and run those test i picked in get_action methods
end
end

startpage.rb
require ‘watir-webdriver’
class Startpage

def verify_elements_present
#Verify that expected elements are present
if @driver.find_element(:id, “q”)
puts “true”
else
puts “false”
end
end
end

def assert_all_text
# Verify expected test are present
end

Best Regards
Mattias

As far as I can see you haven’t required ‘startpage’, and I think you’ll
want require_relative if you’re doing this all with local files.

Is there any particular reason for breaking your browser control into
multiple classes? I would have thought a single class (possibly extended
into multiple files) would suffice, or maybe a class and a module if you
want to break the commands down a bit.

You’ll probably want to get the user input before starting your browser,
in the first instance at least.

You’ll probably want to use something like
if @driver.element(:id, “q”).present?
instead of
if @driver.find_element(:id, “q”)
as the first returns a boolean while the second returns an object
(possibly an exception)

Joel P. wrote in post #1087292:

As far as I can see you haven’t required ‘startpage’, and I think you’ll
want require_relative if you’re doing this all with local files.

Is there any particular reason for breaking your browser control into
multiple classes? I would have thought a single class (possibly extended
into multiple files) would suffice, or maybe a class and a module if you
want to break the commands down a bit.

You’ll probably want to get the user input before starting your browser,
in the first instance at least.

You’ll probably want to use something like
if @driver.element(:id, “q”).present?
instead of
if @driver.find_element(:id, “q”)
as the first returns a boolean while the second returns an object
(possibly an exception)

To start with a big thank you for you anwers Joel!

My plan is to have one class for each page that i will test and all the
test for that page within this class. I will probably verify about 30
pages. But maybe not a good idea?

I agree, sounds logical to have the input before. Do you have other
suggestions for how to handle which test cases that should be run? Any
common standard?

Thank you i dident know the syntax!

Best Regards
Mattias

You’re using an instance variable ‘@’ for your browser. I think if
you’re going to use multiple classes you might be better off with a
class variable ‘@@’ or a global variable ‘$’ to ensure that you can hand
the browser control back and forth without any problems. I’m quite new
to OOP myself, but I suspect that an instance variable might cause you
problems later on.

I have absolutely no idea whether it’s a good plan to have a separate
class for each test sequence. I just know that’s not how I went about
doing it. Experiment a bit, it’ll be interesting to find out what
happens :slight_smile:

I don’t know what your situation is, so I can’t really comment on your
user interactions. What I did was run my application as an rbw extension
and build a GUI with Tcl/Tk. Much prettier than a console app!

Feel free to keep asking questions and coming up with ideas; playing is
learning.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs