experiment with page object model for automation tests

RESOLVED FIXED

Status

Testing Graveyard
WebQA
RESOLVED FIXED
8 years ago
4 months ago

People

(Reporter: vish_moz, Unassigned)

Tracking

Details

Attachments

(14 attachments)

(Reporter)

Description

8 years ago
Created attachment 455375 [details]
Base Page class

Here is a sample test case (test_search_on_home_page) which uses
the page object model.

1. page.py -  The base class for all pages. It has the most common functions
that need to be performed on any web page. All other individual page classes will be derived (parent - child) from page.py for any web app (AMO/SUMO)


2. support_home_page.py - child class of page.py. All web elements on the Support Home page (title,main_search_box,search_button) are defined as class variables. All operations that can be performed on these elements are defined as functions
(click_log_in_link, do_search_on_main_search_box)

3. main test case (test_search_on_home_page.py) - In the main TC you import those pages that will be hit.  In this test case we will be hitting Support Home Page, Search page, Advanced Search page & Login page.

Advantages:
1. You don't have a functions library (AMO_functions/Sumo_functions) which grows over time. You have the functions spread over different page classes.
2. Main test case looks cleaner. In the traditional model a sample code looks like:
        sel.open("/en-US/kb/")
        sel.type("fsearch-new", "iphone")
        sel.click("searchsubmit-new")
        sel.wait_for_page_to_load("30000")

  With the page model object, the same code in the TC will look like:
    
       support_home_page_obj.go_to_support_home_page(sel)  
       support_home_page_obj.do_search_on_main_search_box(search_term,search_page_obj,sel)

Disadvantages:
1. The selenium object gets passed around twice, from main test case -> individual page class -> parent page class
2. Too many imports in the TC

Feel free to comment/critique.
(Reporter)

Comment 1

8 years ago
Created attachment 455377 [details]
support home page class
(Reporter)

Comment 2

8 years ago
Created attachment 455378 [details]
search page class
(Reporter)

Comment 3

8 years ago
Created attachment 455379 [details]
advanced search page class
(Reporter)

Comment 4

8 years ago
Created attachment 455380 [details]
main test case
(Reporter)

Updated

8 years ago
Attachment #455377 - Attachment mime type: text/x-python-script → text/plain
(Reporter)

Updated

8 years ago
Attachment #455379 - Attachment mime type: text/x-python-script → text/plain
(In reply to comment #1)
> Created an attachment (id=455377) [details]
> support home page class

I don't find the disadvantages to be significant problems.  One disadvantage I would add, perhaps a better word is cost, is that it's a major restructuring of test cases and supporting classes.  Everything needs to be build from scratch, although pieces such as locators can be copied from the current shared libraries.

I think the simple noun/verb (page/action) structure is a natural fit for our automated tests.  The shared libraries will inevitably continue to grow.  The page object model offers a logical way to segment the functions and locators making code maintenance and creating new tests easier.
(Reporter)

Comment 6

8 years ago
Created attachment 456915 [details]
login page
(Reporter)

Comment 7

8 years ago
Created attachment 459485 [details]
Base page class (updated)
(Reporter)

Comment 8

8 years ago
Created attachment 459486 [details]
Sumo page class (child of Page)

All common elements of SUMO pages should go into sumo_page.py which is child class of Page.py
sumo_page.py will have elements like log in link,log out link, My Account link etc. It can also have common header/footer elements that are available across all sumo pages.
(Reporter)

Comment 9

8 years ago
Created attachment 459488 [details]
support home page class (updated)
(Reporter)

Comment 10

8 years ago
Created attachment 459489 [details]
search page (updated)
(Reporter)

Comment 11

8 years ago
Created attachment 459490 [details]
login page (updated)
Attachment #459486 - Attachment is patch: true
Attachment #459486 - Attachment mime type: text/x-python-script → text/plain
(Reporter)

Updated

8 years ago
Attachment #459488 - Attachment mime type: text/x-python-script → text/plain
(Reporter)

Updated

8 years ago
Attachment #459489 - Attachment mime type: text/x-python-script → text/plain
(Reporter)

Updated

8 years ago
Attachment #459490 - Attachment mime type: text/x-python-script → text/plain
(Reporter)

Comment 12

8 years ago
Created attachment 459493 [details]
advanced search page (updated)
(Reporter)

Updated

8 years ago
Attachment #459493 - Attachment mime type: text/x-python-script → text/plain
(In reply to comment #7)
> Created attachment 459485 [details]
> Base page class (updated)

adding the selenium parameter to the class is Excellent.
This project might be a good opportunity to create some best practices for css locators.  For example:

- Abbreviations, such as . or #, allow for shorter locators since they represent a specific attribute.  But, a person who only occasionally reads will need lookup the meaning of the symbols when they need to understand the locator.  Shorter or easier to read?

- When defining an 'any descendant' relationship should an operator be used (> or *) instead of a space?  Are there situations where specifying direct descendant is preferable over any descendant?
(Reporter)

Comment 15

8 years ago
Created attachment 467204 [details]
forums page
(Reporter)

Comment 16

8 years ago
Created attachment 467205 [details]
test forum reply logged out
(Reporter)

Comment 17

8 years ago
page model object has been implemented:
http://viewvc.svn.mozilla.org/vc/projects/sumo/tests/frontend/python_tests/page.py?view=log
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Updated

4 months ago
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.