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.
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
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
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
17. Checking State for Flow Control
• Synchronization Issues
• Your Test “Already Knows”
• What driver are you using?
• What Config determined the driver?
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
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
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