Creating automated functional tests of your web application with Selenium IDE is quick and easy, but leads to massive duplication in your test scripts. See why this duplication is a problem, and how to address it using a simple design pattern called the Page Object.
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Using The Page Object Pattern
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
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
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
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
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
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