Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Page Objects - You're Doing it Wrong by Titus Fortner

94 views

Published on

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.

Published in: Software
  • Attended Titus' presentation of the slide deck in Belfast at the Selenium Software Tester Meetup. Great presentation and speaker. Many thanks for your time and this slide deck, sir.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Page Objects - You're Doing it Wrong by Titus Fortner

  1. 1. Page Objects: You’re Doing It Wrong #badpageobject Titus Fortner Sr Solution Architect at Sauce Labs @titusfortner
  2. 2. 2 • @titusfortner • Former SDET • Open Source • Senior Solution Architect at Sauce Labs! © Sauce Labs, Inc. Titus Fortner
  3. 3. Ground Rules 1. “My Opinions Are Correct” 2. I have too many a lot of Opinions 3. Make Informed Decisions
  4. 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. 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. 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. 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. 8. Conventions for Maintainability ● Consistency ● Principle of Least Surprise
  9. 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. 10. Page Object Principles ● Avoid Imperative ● Avoid Nondeterministic ● Avoid Complicated Constructors ● Avoid Coupling ● Avoid Assertions ● Avoid Ambivalence
  11. 11. be Declarative not Imperative 1
  12. 12. • How • Implementation Logic • Specific Details • All Data Declarative Imperative • What • Business Logic • Big Picture • Contextual Data
  13. 13. Imperative Example
  14. 14. Declarative Example
  15. 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. 16. be Deterministic not Nondeterministic 2
  17. 17. Checking State for Flow Control • Synchronization Issues • Your Test “Already Knows” • What driver are you using? • What Config determined the driver?
  18. 18. Subclass / Factory / Interface
  19. 19. use Simple Constructors not Magic Constructors 3
  20. 20. Validating State in Constructor ● Good Idea – User shouldn’t care how state is set to arrive on the page
  21. 21. What Your Users Will Do… ● Relying on “Magic” things in Insufficient Places is Less Clear
  22. 22. Page Object Should Know Where it Lives ● Implement a visit method to be explicit • Re-use instead of Re-implementing • Be Direct!
  23. 23. be De-Coupled not Coupled 4
  24. 24. Coupled Objects
  25. 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. 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. 27. De-Coupled
  28. 28. do Raise Exceptions do not Make Assertions 5
  29. 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. 30. Better Information
  31. 31. do Consider Method Intent do not Use Ambivalent Methods 6
  32. 32. Common Test Pattern
  33. 33. Unhelpful Information Not finding an element isn’t the real problem Some previous step unsuccessful
  34. 34. Intentional Method
  35. 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. 36. How About You? Tweet at me @titusfortner Your Bad Page Object Experiences #badpageobject
  37. 37. Thank you.

×