Picture a login screen, such as The-Internet / Login.
On this LoginPage, there is:
- a heading: Login Page
- a user name textbox with the label, "Username"
- a password textbox with the label, "Password"
- a login button, with the role of a button, and the name of "Login"
- a flash message that appears if you enter invalid credentials such as "NotAUser" and "NotAPassword".
If you successfully log in with "tomsmith" and "SuperSecretPassword!, there is a SecureArea:
- a heading: "Secure Area"
- a flash message "You logged into a secure area!"
- a Logout button.
Sure, you could interact with each web element in your test... but what if the username text box locator changes? You would have to update multiple tests every time the element changed.
... Instead, you could place it in a Page Object, something that Playwright handles well!
"A page object represents a part of your web application. An e-commerce web application might have a home page, a listings page and a checkout page. Each of them can be represented by page object models.
"Page objects simplify authoring by creating a higher-level API which suits your application and simplify maintenance by capturing element selectors in one place and create reusable code to avoid repetition".
Using Playwright's Built-In Test Runner? Or Something Else?
You may have noticed in https://playwright.dev/docs/pom that there are two different styles of page objects. One for "Test". One for "Library".
- Test: If you are writing actual Playwright test suites, and Playwright's built in test runner, use the Test section as a guide when creating page objects.
- Library: If you are integrating Playwright into an existing test framework such as Jest or Cucumber and just want browser automation, instead of having pre-built page fixtures, etc, you can use this format.
