1.
Using the Page Object
Pattern to Improve
Functional Test Maintainability
Dante Briones
Principal Consultant
Electronic Ingenuity LLC
http://electronicingenuity.com
Friday, 07 August, 2009

2.
The Page Object Pattern
• Technique for structuring test code that:
• Promotes reuse and reduces duplication
• Makes tests readable
• Makes tests more robust (less brittle)
• Improves maintainability, particularly if
the application is rapidly evolving
Friday, 07 August, 2009

3.
The Page Object Pattern
• Demos will be coded in Java
• Everything we discuss is applicable to other
strongly-typed languages (e.g. C#)
• Most things are applicable to dynamically-
typed languages (e.g. Ruby, Python, Perl)
Friday, 07 August, 2009

4.
Selenium IDE
Quick Poll
• How many using Se IDE?
• How many create tests primarily through
record & playback?
Friday, 07 August, 2009

5.
Selenium IDE
It’s Great Because:
• It’s Free
• It’s Free
• Requires little or no programming
experience
Friday, 07 August, 2009

6.
Selenium IDE
It falls short because:
• Selenese is not a programming language
• No support for loops/iteration
• No support for conditionals (if...else)
• No way to eliminate duplicated code!
Friday, 07 August, 2009

7.
Selenium IDE
Why is duplication bad?
• Has this ever happened to you?
• A tiny change to the app causes several
test failures?
• Let’s see an example
Friday, 07 August, 2009

8.
Demo
Friday, 07 August, 2009

9.
Selenium IDE
Why is duplication bad?
• Fixing the tests will require more work
than the change that caused the failure
• Duplication makes code less maintainable
Friday, 07 August, 2009

10.
Selenium IDE
Summary
• Great productivity for the first few tests
• Maintainability decreases as the test suite
grows
• How can we do better?
Friday, 07 August, 2009

11.
Start Coding Your Tests
a.k.a.
“Write tests in a programming language”
Friday, 07 August, 2009

12.
Coding Your Tests
Quick Poll
• How many are using Selenium RC?
Friday, 07 August, 2009

13.
Coding Your Tests
How does this help?
• We can eliminate duplication by building
abstractions
• Let’s see an example of this
Friday, 07 August, 2009

14.
Demo
Friday, 07 August, 2009

15.
Coding Your Tests
What happens next?
• All commonly used methods get pulled into
the base class of all tests
• As the test suite grows, so does the base
class
• Uh oh...the base class starts getting too big
Friday, 07 August, 2009

16.
Coding Your Tests
How Big is Too Big?
• You can’t tell someone else has already
written the code you’re about to write
• Frequent version control conflicts
• Maintenance is an issue again
Friday, 07 August, 2009

17.
Coding Your Tests
How to rein in your base class?
• Observation: For any given page, most of
the behavior does not apply
• Example: you can’t change your password
on the “view cart” page
• What if we moved the page-specific
behavior into a corresponding class?
• Voila! The Page Object is born
Friday, 07 August, 2009

18.
The Page Object
Friday, 07 August, 2009

19.
The Page Object
What does it do?
• Consolidates the code for interacting with
any given UI element
• Allows you to model the UI in your tests
Friday, 07 August, 2009

20.
The Page Object
What does it do?
• Exposes methods that reflect the things a
user can see and do on that page, e.g.
• addItemToCart(), getPrice()
• getEntryTitle(), saveDraft(), publishEntry()
• Hides the details of telling the browser
how to do those things
Friday, 07 August, 2009

21.
Demo
Friday, 07 August, 2009

22.
The Page Object
Results
• Test code is very readable
• No duplication of Selenium API calls
• Interactive documentation via Ctrl-Space
• Eminently reusable code
Friday, 07 August, 2009

23.
The Page Object
Results
• This technique is framework-agnostic
• Has been used with Selenium, WebDriver
(Selenium 2.0), Watir, and others
• I’ve even used it to drive desktop apps
Friday, 07 August, 2009

24.
The Page Object
Results
• Because it encapsulates the details of the
test framework API:
• You can use this technique to simplify the
process of swapping frameworks
• In theory, you only need to reimplement
the Page base class.
Friday, 07 August, 2009

25.
But wait, there’s more!
It gets better!
• Page Objects improve maintainability
• They also provide an opportunity to make
test creation extremely quick (and maybe
even fun!)
• How? Page Objects + Method Chaining
Friday, 07 August, 2009

26.
Method Chaining
What’s method chaining?
• Change the signature of user behavior
methods so that they return the page
object itself
• Allows multiple behavior methods to be
called in sequence
Friday, 07 August, 2009

27.
Method Chaining
What will it do for me?
• Removes for “code clutter”
• Tests become even more readable
Friday, 07 August, 2009

28.
Method Chaining
How does it work in practice?
• All Page Object methods return a
reference to a Page Object
• If the “user action” moves the focus to a
different page, the method should return
that page object
• Otherwise, return the same page object
• Time for an example
Friday, 07 August, 2009

29.
Demo
Friday, 07 August, 2009

30.
Method Chaining
Results
• Test code is even more readable
• Very quick to write
• (Actually kinda fun. Don’t tell anyone!)
Friday, 07 August, 2009

31.
Method Chaining
Caveats
• Dependent on tool support
• Lots of options: IntelliJ IDEA, Eclipse,
NetBeans, VisualStudio
Friday, 07 August, 2009

32.
Method Chaining
Caveats
• Tool support depends on language
• Excellent support for strongly typed
languages like Java and C#
• Support is “up and coming” for
dynamically typed languages (Ruby,
Python, and Perl)
Friday, 07 August, 2009

33.
The Page Object Pattern
• Technique for organizing test code that:
• Promotes reuse and reduces duplication
• Makes tests readable
• Makes tests more robust (less brittle)
• Improves maintainability, particularly if
the application is rapidly evolving
• Is just as quick record & playback!
Friday, 07 August, 2009

34.
Q &A
Friday, 07 August, 2009