We explored Page Object design pattern to some of the more common, and sometimes frustrating, object configurations found on the internet. Learn how proper application of this pattern enables you to leverage Selenium’s power to produce concise, readable, and maintainable automated tests. We tackled challenging DOM configurations such as Messy tables Frames Random identifiers Third part frameworks like JQuery and Moment HTML5 video players and more with Java and Selenium 3. Learn how solving these tricky problems with the correct techniques leads to more robust tests while saving scripting time! For more information, please visit www.QualiTestGroup.com

1. Designing for the Internet
Page Objects for the Real World

2. Intro
| Christopher Livett – Solution Architect
| Working with QualiTest UK for 8 years
| Specialist in test automation, performance
testing and leading technical delivery
| Helped define and implement numerous
test automation solutions using a variety of
tools, frameworks and languages
| Experienced in implementing Continuous
Integration, Continuous Delivery and
DevOps processes.
2

3. Introducing the Page Object Model
3

4. What is a
Page Object
Model?
| A pattern for modeling the UI components of an application as
objects to be consumed by test code
| Provides the test with a representation of the services offered
by a page
| Contains the deep knowledge of the structure of the HTML of
a page and its components
| Abstracts the test logic away from direct interaction with the
WebDriver API and System-Under-Test wherever possible.
4

5. Why Page
Object
Model?
| Expose page and component services rather than mechanics
| Write concise tests that exercise functionality, not technical
details
| Create maintainable tests by isolating the effect of UI change
on test code
| Produce readable tests by keeping implementation details out
of test code.
5

6. Layers of Abstraction
| Tests are comprised of steps
| Steps interact with pages
| Pages provide services and key components
| Operations on pages occur without any
knowledge of page structure
| Pages are comprised of elements
| Each element represents a single item on
a page that can be interacted with
| Text, buttons, fields, images, etc.
6
Steps
Pages
Elements
Tests

7. Design Considerations
| PageObject base class
| Interface with Selenium’s PageObjectFactory
| Provides easy access to the WebDriver
instance it is created with
| Optionally provision for detecting that the page
has loaded properly
| All Page Objects should be derived from
this base class
| Not all pages should be represented in
their entirety by a Page Object.
| Components
| Web applications may consist of lots of
elements on a single page, or no clear
distinction of “pages”
| Instead of a Page Object representing a whole
page, it can represent a component on a page
| Judgement as to whether to use pages,
components, or both
| No Page Object should be “bigger than
your head”
| https://gist.github.com/RiverGlide/7718ab70f9
d1ee0eddbf8bcf95887555.
7

8. Page Object Model vs Screenplay Pattern
8

9. Page Object vs Screenplay
| Page Object
| Model for abstracting implementation from
logic
| Most commonly used standard in test
automation
| Has been used in very large, stable solutions
| Designed to reduce code duplication,
encourage code re-use and make tests more
maintainable
| Does not strictly follow SOLID principles.
| Screenplay
| Design pattern for writing human-readable
tests with layers of abstraction
| Comprised of:
• Actors – Who is using the system
• Tasks – What are they doing
• Actions – How are they going to do it
• Web Pages – Where are the elements they need
| Breaks Page Objects in to Actions and Web
Pages
| Adheres more closely to SOLID principles.
9

10. Page Object
vs
Screenplay
continued
| Purpose of today is not debate Page Object vs Screenplay
| Both have proven to be viable solutions for writing
maintainable automated tests
| Principles learned in writing good quality Page Objects can be
refactored into Screenplay tests.
10

11. 11

12. Introducing
| Demonstrating the Page Object model requires a testing
framework
| Serenity is an open source Java (and recently JavaScript)
library to speed up writing tests; including:
| Complete WebDriver testing framework
| Parallel execution of tests using JUnit, Cucumber or JBehave
| Integration with SauceLabs, Jira, and other testing tools
| Detailed reporting
| Supports both the Page Object and Screenplay pattern
| Well used across the industry.
12

13. Creating our first test
| Introducing creating a Serenity test from
scratch
| Test:
| Given I start on the form authentication page
When I log in as Tom Smith
Then I see the secure area
| Framework:
| Serenity, Selenium, JUnit and Maven
| Execute on single Chrome instance
| Hard-coded test data
13
Steps
FormAuthenticationSteps
Pages
FormAuthenticationPage
SecureAreaPage
Elements
usernameField
passwordField
etc.
Test
FormAuthentication

14. Demonstration 1:
Creating the authentication test
14

15. Challenging Page Object Models
15

16. Tables
| Common tasks
| Iteration
| Query for rows
| Sorting
| Row actions (like clicking edit or delete
buttons)
| Common Challenges
| Lack of unique identifiers
| Lack of relationships between column headers
and cells within rows
| Index and other related math can make code
messy.
16

17. Potential
Solutions
| Complex CSS or XPATH for finding data
| E.g. //table[@id=’table1']//tr[td//text()[contains(., '{0}')]]/td[3]
| Fast, re-usable and can be extended to find data within the table
| Difficult to create, read and update on change
| Parse whole table
| Cycle through each row, storing all data in to the ‘Row’ object
| Table object can then be stored and passed around to be usable by
code
| Slow to do 1st capture and requires re-capture on change
| Easy to use, understand, update
| Row iterator
| Similar to parsing whole table
| Parse row-by-row as needed until needed data found
| Speed depends on how much data is required.
17

18. Demonstration 2:
Table row iterator
18

19. Frames
| Common tasks
| Interacting with nested frames
| Interacting with iFrames
| Switching between pages and frames
| Common Challenges
| Frames can be from different sources
| iFrames may need to be loaded
| Needing to move back outside of frames.
19

20. Demonstration 3:
Handling iFrames
20

21. Dynamic Pages
| Many systems are dynamic by nature
| Thick client (Angular, JQuery)
| CMS
| Systems may not be made with testing in
mind
| Common Challenges
| IDs and classes may change each page load
or change
| Elements may move on the page
| Tests may change the page for other tests.
21

22. Demonstration 4:
Changing Buttons
22

23. JQuery
| JQuery and similar libraries introduce
complex behaviours to websites
| Almost endless possibility of features that
can prove challenging for test automation
| Common Challenges
| Lazy loading / infinite scrolling
| Hover actions
| Hidden elements
23

24. Demonstration 5:
Mouse-over elements and file downloads
24

25. Demonstration 6:
Infinite Scroll
25

26. HTML5 Video Player
| Common Tasks
| Play
| Pause
| Control volume
| Seeking
| Reload video
| Checking state
| Common challenges
| Video controls may not be interacted with by
WebDriver
| Controls may have difficult to identify selectors
| Videos may be in different states.
26

27. Demonstration 6:
Controlling YouTube videos
27

28. Conclusion
| We have shown one solution to each problem
| Different websites and situations may require different
solutions
| Complex pages could and should be broken into
‘Components’
| Page Objects may not be the perfect solution
| Easily become large and complex
| Can be difficult to maintain
| Break SOLID principles
| but:
| They provide abstraction of logic and implementation
| Allow creating unique solutions to unique problems
| Can be easily understood, created and updated.
28

29. 29

30. www.QualiTestGroup.com
Thank You