Workflow:Webdriverio Webdriverio Page Object Pattern
| Knowledge Sources | |
|---|---|
| Domains | Browser_Automation, Test_Architecture, Design_Patterns |
| Last Updated | 2026-02-12 01:30 GMT |
Overview
End-to-end process for structuring WebdriverIO test suites using the Page Object Model design pattern for improved maintainability and reusability.
Description
This workflow demonstrates how to encapsulate page-specific selectors and interactions into reusable Page Object classes. The pattern separates test logic (assertions and flow) from page knowledge (selectors and page-specific methods). A base Page class provides shared behavior like navigation, and specific page classes extend it with element getters and interaction methods. Test specs then import page objects and call high-level methods instead of directly manipulating selectors. When the UI changes, only the page object needs updating rather than every test.
Usage
Execute this workflow when building a test suite that will grow beyond a handful of tests, when multiple tests interact with the same pages, or when UI changes are expected to be frequent. The Page Object pattern is the recommended structural pattern for any non-trivial WebdriverIO test suite.
Execution Steps
Step 1: Create Base Page Class
Define a base Page class that contains methods shared across all pages, such as open(path) for navigation. This class serves as the parent for all specific page objects and provides a consistent interface for common operations.
Key considerations:
- The base class typically has an open() method that calls browser.url()
- It may include shared helper methods (e.g., wait for page load, get page title)
- Export the class so specific pages can extend it
- Use JavaScript/TypeScript class syntax for clean inheritance
Step 2: Define Page Object Classes
Create a class for each page (or major component) of the application being tested. Each class extends the base Page class and defines element selectors as getter properties using $() and $$(). Add page-specific interaction methods that encapsulate common user actions on that page.
Key considerations:
- Use getter properties (get username() { return $('selector') }) for element access
- Getters are lazy-evaluated, returning fresh element references each time
- Add methods for multi-step interactions (e.g., login(user, pass) that fills both fields and clicks submit)
- Export a singleton instance (export default new LoginPage()) for convenient import
- Keep selectors private to the page object; tests should not know about selectors
Override the base open() method in each page object to provide the page-specific URL path. This allows tests to navigate to any page by calling page.open() without knowing the URL structure.
Key considerations:
- Each page knows its own URL path
- The base class open() method is called with super.open(path)
- URL paths should be relative to the baseUrl configured in wdio.conf
Step 4: Write Tests Using Page Objects
Write test specs that import page objects and use their methods and getters to interact with the application. Tests focus on behavior and assertions rather than element selection and low-level interactions. This makes tests readable and resilient to UI changes.
Key considerations:
- Import page object singletons at the top of test files
- Call page.open() to navigate
- Access elements through page object getters: await LoginPage.username.setValue(...)
- Use page object methods for multi-step actions: await LoginPage.login(user, pass)
- Assertions use expect-webdriverio matchers on page object elements
Step 5: Organize File Structure
Establish a consistent directory structure that separates page objects from test specs. A common convention is a pageobjects/ directory alongside a specs/ directory, with the base page class and specific page classes clearly organized.
Key considerations:
- Common structure: test/pageobjects/ for page classes, test/specs/ for test files
- Name files to match the page they represent (e.g., login.page.ts, dashboard.page.ts)
- The base class is typically named page.ts or base.page.ts
- Large applications may further organize pages by feature area