QA/Execution/Web Testing/Docs/Automation/page object model project

From MozillaWiki
Jump to: navigation, search

Project:

Page Object Model

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. sumo_page.py - 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.


3. 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)

4. 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

Goal:

Convert existing AMO/SUMO test cases to the new page object model where all apps (AMO/SUMO)

share a common class page.py on the parent-level and every new web-page will be a child class of

page.py

Phase 1:

Convert 4 most frequently visited SUMO web-page to page object model.

Convert 6-8 of existing test cases that use these 4 pages.

Estimated date of completion: July 30th

    • Status as of 08/19/2010
    • *_page.py classes completed:
   1. contribute_page.py
   2. forums_page.py
   3. login_page.py
   4. refine_search_page.py
   5. search_page.py
   6. sumo_page.py
   7. support_home_page.py
   8. support_website_forums_page.py
    • tests completed:
   1. test_contribute_redirect
   2. test_forum_new_post
   3. test_forum_pagination
   4. test_forum_reply_logged_out
   5. test_login
   6. test_other_firefox_support
   7. test_search_advanced_checked
   8. test_search_advanced_links
   9. test_search_decoding
  10. test_search_nonnumeric_pages
  11. test_search_num_results
  12. test_search_old_redirect
  13. test_search_on_home_page
  14. test_tiki_search_results


Standards:

1. suffix the web element varibale names with _box, _link etc.

2. use verbs for function names like click_log_in_link, do_search_on_main_search_box

3. page instances should be suffixed with _page_obj

4. if performing an action on a particular page results in opening another new page then that new page's instance should be passed as a parameter to the function. For e.g. in the RefineSearchPage.py class we have a function do_search_on_knowledge_base(self, search_query,search_page_obj,selenium) . Note, search_page_obj is passed as a parameter.