Page Objects are the most commonly used abstraction pattern for functional UI Tests. They have the ability to enable users with little Selenium knowledge to write sophisticated tests against an application at scale, while reducing the maintenance costs as the application changes. Based on Sauce Labs Solution Architect code reviews, though, it is one of the most poorly understood and abused tools in a team’s framework. As an SDET at 5 companies before joining Sauce Labs, Titus has tried a number of different approaches and knows first-hand what works well and what can cause problems. Experienced people will have disagreements with many of the points he outlines, and he presents both sides along with the reasons for his preferences.

1. Page Objects:
You’re Doing It Wrong
#badpageobject
Titus Fortner
Sr Solution Architect at Sauce Labs
@titusfortner

2. 2
• @titusfortner
• Former SDET
• Open Source
• Senior Solution Architect
at Sauce Labs!
© Sauce Labs, Inc.
Titus Fortner

3. Ground Rules
1. “My Opinions Are Correct”
2. I have too many a lot of Opinions
3. Make Informed Decisions

4. Law of the Instrument
● You Can Make Anything “Work”
○ How long for a new employee to understand?
○ How long for your replacement to understand?
○ Have you considered alternatives?

5. My Priors
● End to End DOM to Database
● Scalable Test Automation Requires Tests be
○ Atomic, Autonomous, and Short
● Optimize Maintainability not “Correctness”
● Prefer Simple/Clear to Easy/Fast

6. A Page Object is…
an object oriented class that stores information about the services provided
by a specific view in an application’s User Interface.
● Browser vs Mobile App
● Desktop Browser vs Mobile Browser
● Page / Modal / Section
● Action Methods & Element Definitions

7. What Problems Do Page Objects Solve?
● Maintenance, Maintenance, Maintenance
● Separation of Concerns
● DRY
A place for everything and everything in its place
-Benjamin Franklin

8. Conventions for Maintainability
● Consistency
● Principle of Least Surprise

9. Page Object Critiques
● Abstract LESS!
○ YAGNI
○ Keep code base smaller by not over-abstracting
● Abstract MOAR!
○ Single Responsibility Principle
○ Keep classes smaller with more of them

10. Page Object Principles
● Avoid Imperative
● Avoid Nondeterministic
● Avoid Complicated Constructors
● Avoid Coupling
● Avoid Assertions
● Avoid Ambivalence

11. be
Declarative
not
Imperative
1

12. • How
• Implementation Logic
• Specific Details
• All Data
Declarative Imperative
• What
• Business Logic
• Big Picture
• Contextual Data

13. Imperative Example

14. Declarative Example

15. Things That Encourage Imperative
● “Keyword Driven” Testing
○ Robot Framework
● “Data Driven” Testing (BDD?)
● Test Libraries with special matchers
○ Nightwatch.js
○ Site Prism gem
○ Selenide jar
● Property Files

16. be
Deterministic
not
Nondeterministic
2

17. Checking State for Flow Control
• Synchronization Issues
• Your Test “Already Knows”
• What driver are you using?
• What Config determined the driver?

18. Subclass / Factory / Interface

19. use
Simple Constructors
not
Magic Constructors
3

20. Validating State in Constructor
● Good Idea – User shouldn’t care how state is set to arrive on the page

21. What Your Users Will Do…
● Relying on “Magic” things in Insufficient Places is Less Clear

22. Page Object Should Know Where it Lives
● Implement a visit method to be explicit
• Re-use instead of Re-implementing
• Be Direct!

23. be
De-Coupled
not
Coupled
4

24. Coupled Objects

25. Fluent Pattern
● Errors are not captured at compile time
● Debuggers / Stack Trace inaccuracies
● Weird Names to make fun sentences in your code
● Subclasses must explicitly define all return values from the fluent
interface

26. PO Pattern Specific Objections
● Code repeatability: Options for re-using a LogIn Modal from Cart & Home Page?
○ Different Classes? Methods?
○ Intermittently skip returning instance values
● Your Deterministic test “Already Knows” what it is doing;
○ Don’t store the same information in multiple places
● Is the Return Value Obvious?
● “Visit” method provide state
● Atomic test theoretically only needs one Page Object

27. De-Coupled

28. do
Raise Exceptions
do not
Make Assertions
5

29. Intention
I Have Evaluated the “Functionality I Care About” and Have
Determined that it: is / is not
Working as Intended
Vs
I am unable to evaluate whether the “Functionality I Care
About” is working as intended

30. Better Information

31. do
Consider Method Intent
do not
Use Ambivalent Methods
6

32. Common Test Pattern

33. Unhelpful Information
Not finding an element isn’t the real problem
Some previous step unsuccessful

34. Intentional Method

35. Anti-Patterns that didn’t make the cut
● Don’t rely on standard Error Messages
● Use Additional Classes to avoid overloading the Base Page
● Avoid too many levels of subclass
● Allow a Page Object to define ”success” as an implementation detail
● Avoid Multiple Inheritance
● Avoid Soft Assertions
● Don’t Define Methods & Elements that you don’t already have a test for
● Do not look for the absence of an element
● All Reusability needs to exist in Page Object not in Steps / Test Code

36. How About You?
Tweet at me
@titusfortner
Your Bad Page Object Experiences
#badpageobject

37. Thank you.