QA/Execution/Web Testing/Docs/Automation/Testcases/AMO POM Overview

Overview

As suggested by the name, the Page Object Model organizes class methods and static values around individual web pages. The following snippet of code gets the theme count that's displayed in the header of the themes landing page:

# Create objects for the AMO home page and themes landing page
amo_home = AmoHomePage.amo_home_page(self.selenium) 
themes_landing = ThemesLandingPage.themes_landing_page(self.selenium) 
...
# Open the base page
amo_home.open_base_page() 
...
# Navigate to the themes landing page
amo_home.go_to_themes_landing(themes_landing) 
...
# Get the themes count from the page header
themes_count = themes_landing.get_themes_count_from_header_as_integer()

The amo_home object, an instance of the AMO home page class, has methods related to that page.  Similarly themes_landing object, an instance of the themes landing page class, has methods for the themes landing page.

open_base_page( ) calls selenium.open("/"), which opens the base page set in the selenium instance.

go_to_themes_landing( ) clicks on the link to the themes landing page.  The method is called with the AMO home page object since that is the current page.  go_to_themes_landing( ) checks that the themes landing page opened successfully using a method in the themes landing page class, which is passed via the themes_landing parameter.  If the themes landing page was not opened an exception is thrown.

get_themes_count_from_header_as_integer( ) returns the add-on count, as an integer, displayed in the header.  If a count cannot be returned it throws an exception. Errors could include the element not being present, the expected accompanying text not found in the element, or the count being a negative number.

Getting and verifying data

A test case gets data from a page using methods defined in page classes.

• The methods may check that the element has any expected text that labels the data.
• The data is converted to an appropriate data type (ex: integer, date)
• Data range constraints are checked (ex: a "count" is not negative; text matches standard patterns)

Page classes might also have methods to verify complex elements which contain related attributes or sub-elements.  The methods allow for simpler test case by moving to the page class the code for retrieving elements and attributes, comparing values, and handling exceptions.  Elements which may require verification methods could include: a list of links that are expected to have a common pattern in their URLs; a Star Rating element that has multiple attributes which refer to the same 'star count' value.

Verfication logic in test cases is normally simple comparasions. For example checking items sort order by comparing the values on two items; checking a search page and browse page contain the same information for the same add-on.

Exception handling

Methods that throw exceptions which are informational will typically have the option the save exceptions for later reporting via a SaveExceptions object (see the utilities class page for more information).  The default is to throw exceptions immediately.  Informational exceptions are found in methods that verify retrieved data, and while they are errors worth reporting, any exceptions would not affect how the test case operates.  By contrast, methods that retrieve data or navigate would normally not have an option to save exceptions and therefore always throw an exception.  It would be up to the test case to capture any exceptions with a try-except if it wishes to continue when an element is missing or a navigation appears to fail, and save it using save_exception( ) from the SavedExceptions class.

Page class hierarchy

The class for a web page inherits methods and data from parent classes as described in the table below.

page class for an individual page (ex: personas landing page)	child class of an add-on type	locators and methods for elements unique to the page. (ex: get the title for a theme on the page; click on a theme's detail page link)
page class for an add-on type (ex: personas)	child class of AmoPage class	locators and methods for elements appears on multiple pages for the add-on type. (ex: click on a category from the sidebar menu.)
amo_page.AmoPage	child class of Page	locators and methods for elements that appear on all AMO pages or that apply to multiple add-on types. (ex: page header and footer elements; submitting a search using the query form in the page header)
page.Page		methods that call selenium APIs. Many call their selenium counterpart of the same name and might add "good practices" logic, such as calling wait_for_page_to_load( ) after click( ) or open( ).