Designing for the internet - Page Objects for the Real World
Download as PPTX, PDF1 like695 views
The document introduces the Page Object Model (POM), a test automation pattern for modeling UI components of an application as objects to enhance test code efficiency and maintainability. It discusses the advantages of POM, details on abstraction layers, and compares it with the Screenplay pattern, emphasizing their respective benefits for writing maintainable automated tests. Additionally, it highlights challenges associated with dynamic web pages and solutions addressing common testing scenarios.
![Potential
Solutions
| Complex CSS or XPATH for finding data
| E.g. //table[@id=’table1']//tr[td//text()[contains(., '{0}')]]/td[3]
| Fast, re-usable and can be extended to find data within the table
| Difficult to create, read and update on change
| Parse whole table
| Cycle through each row, storing all data in to the ‘Row’ object
| Table object can then be stored and passed around to be usable by
code
| Slow to do 1st capture and requires re-capture on change
| Easy to use, understand, update
| Row iterator
| Similar to parsing whole table
| Parse row-by-row as needed until needed data found
| Speed depends on how much data is required.
17](https://image.slidesharecdn.com/designingfortheinternet-pageobjectsfortherealworldwebinarv4-170708073613/85/Designing-for-the-internet-Page-Objects-for-the-Real-World-17-320.jpg)
Designing for the internet - Page Objects for the Real World
- 1. Designing for the Internet Page Objects for the Real World
- 2. Intro | Christopher Livett – Solution Architect | Working with QualiTest UK for 8 years | Specialist in test automation, performance testing and leading technical delivery | Helped define and implement numerous test automation solutions using a variety of tools, frameworks and languages | Experienced in implementing Continuous Integration, Continuous Delivery and DevOps processes. 2
- 3. Introducing the Page Object Model 3
- 4. What is a Page Object Model? | A pattern for modeling the UI components of an application as objects to be consumed by test code | Provides the test with a representation of the services offered by a page | Contains the deep knowledge of the structure of the HTML of a page and its components | Abstracts the test logic away from direct interaction with the WebDriver API and System-Under-Test wherever possible. 4
- 5. Why Page Object Model? | Expose page and component services rather than mechanics | Write concise tests that exercise functionality, not technical details | Create maintainable tests by isolating the effect of UI change on test code | Produce readable tests by keeping implementation details out of test code. 5
- 6. Layers of Abstraction | Tests are comprised of steps | Steps interact with pages | Pages provide services and key components | Operations on pages occur without any knowledge of page structure | Pages are comprised of elements | Each element represents a single item on a page that can be interacted with | Text, buttons, fields, images, etc. 6 Steps Pages Elements Tests
- 7. Design Considerations | PageObject base class | Interface with Selenium’s PageObjectFactory | Provides easy access to the WebDriver instance it is created with | Optionally provision for detecting that the page has loaded properly | All Page Objects should be derived from this base class | Not all pages should be represented in their entirety by a Page Object. | Components | Web applications may consist of lots of elements on a single page, or no clear distinction of “pages” | Instead of a Page Object representing a whole page, it can represent a component on a page | Judgement as to whether to use pages, components, or both | No Page Object should be “bigger than your head” | https://gist.github.com/RiverGlide/7718ab70f9 d1ee0eddbf8bcf95887555. 7
- 8. Page Object Model vs Screenplay Pattern 8
- 9. Page Object vs Screenplay | Page Object | Model for abstracting implementation from logic | Most commonly used standard in test automation | Has been used in very large, stable solutions | Designed to reduce code duplication, encourage code re-use and make tests more maintainable | Does not strictly follow SOLID principles. | Screenplay | Design pattern for writing human-readable tests with layers of abstraction | Comprised of: • Actors – Who is using the system • Tasks – What are they doing • Actions – How are they going to do it • Web Pages – Where are the elements they need | Breaks Page Objects in to Actions and Web Pages | Adheres more closely to SOLID principles. 9
- 10. Page Object vs Screenplay continued | Purpose of today is not debate Page Object vs Screenplay | Both have proven to be viable solutions for writing maintainable automated tests | Principles learned in writing good quality Page Objects can be refactored into Screenplay tests. 10
- 11. 11
- 12. Introducing | Demonstrating the Page Object model requires a testing framework | Serenity is an open source Java (and recently JavaScript) library to speed up writing tests; including: | Complete WebDriver testing framework | Parallel execution of tests using JUnit, Cucumber or JBehave | Integration with SauceLabs, Jira, and other testing tools | Detailed reporting | Supports both the Page Object and Screenplay pattern | Well used across the industry. 12
- 13. Creating our first test | Introducing creating a Serenity test from scratch | Test: | Given I start on the form authentication page When I log in as Tom Smith Then I see the secure area | Framework: | Serenity, Selenium, JUnit and Maven | Execute on single Chrome instance | Hard-coded test data 13 Steps FormAuthenticationSteps Pages FormAuthenticationPage SecureAreaPage Elements usernameField passwordField etc. Test FormAuthentication
- 14. Demonstration 1: Creating the authentication test 14
- 15. Challenging Page Object Models 15
- 16. Tables | Common tasks | Iteration | Query for rows | Sorting | Row actions (like clicking edit or delete buttons) | Common Challenges | Lack of unique identifiers | Lack of relationships between column headers and cells within rows | Index and other related math can make code messy. 16
- 17. Potential Solutions | Complex CSS or XPATH for finding data | E.g. //table[@id=’table1']//tr[td//text()[contains(., '{0}')]]/td[3] | Fast, re-usable and can be extended to find data within the table | Difficult to create, read and update on change | Parse whole table | Cycle through each row, storing all data in to the ‘Row’ object | Table object can then be stored and passed around to be usable by code | Slow to do 1st capture and requires re-capture on change | Easy to use, understand, update | Row iterator | Similar to parsing whole table | Parse row-by-row as needed until needed data found | Speed depends on how much data is required. 17
- 18. Demonstration 2: Table row iterator 18
- 19. Frames | Common tasks | Interacting with nested frames | Interacting with iFrames | Switching between pages and frames | Common Challenges | Frames can be from different sources | iFrames may need to be loaded | Needing to move back outside of frames. 19
- 21. Dynamic Pages | Many systems are dynamic by nature | Thick client (Angular, JQuery) | CMS | Systems may not be made with testing in mind | Common Challenges | IDs and classes may change each page load or change | Elements may move on the page | Tests may change the page for other tests. 21
- 23. JQuery | JQuery and similar libraries introduce complex behaviours to websites | Almost endless possibility of features that can prove challenging for test automation | Common Challenges | Lazy loading / infinite scrolling | Hover actions | Hidden elements 23
- 24. Demonstration 5: Mouse-over elements and file downloads 24
- 26. HTML5 Video Player | Common Tasks | Play | Pause | Control volume | Seeking | Reload video | Checking state | Common challenges | Video controls may not be interacted with by WebDriver | Controls may have difficult to identify selectors | Videos may be in different states. 26
- 27. Demonstration 6: Controlling YouTube videos 27
- 28. Conclusion | We have shown one solution to each problem | Different websites and situations may require different solutions | Complex pages could and should be broken into ‘Components’ | Page Objects may not be the perfect solution | Easily become large and complex | Can be difficult to maintain | Break SOLID principles | but: | They provide abstraction of logic and implementation | Allow creating unique solutions to unique problems | Can be easily understood, created and updated. 28
- 29. 29
Editor's Notes
- #15: - Start with a blank framework - Begin by pages only having ‘enterUsername’, ’enterPassword’ and ‘submit’ methods, later refactor to include ’authenticate’ method which performs all three - Create test, implement first step, implement page, execute implement next step, implement pages, execute, repeat - Talk through aspects of the test - Show report once test fully passing
- #19: - Create a Row class within the Table page - Create a method to get all row elements by FindElements - Create a method to get an individual user by passing in each rowElement 1-by-1 and returning the found row - Show complete page object being used in tests