Something About Page Object

Page Object

A page object is an object-oriented class that:

  • Serves as an interface to a page of your AUT.
  • Should allow a software client to do anything and see anything that a human can.
  • Provides an interface that’s easy to program to.
  • Hides the underlying widgetry in the window.

Regarding widgets:

  • Text fields should have accessor methods that take and return a string.
  • Check boxes should use booleans.
  • Buttons should be represented by action-oriented method names.

Page Object Make Assertions

  • Page objects themselves should never make verifications or assertions.
  • There is one exception: verifying that the page, and possibly critical elements on the page, were loaded correctly.

Differences of opinion:

  • Some believe including assertions in page objects helps avoid duplication, provides better error messages, and supports a more TellDontAsk style API.
    • However, concerns arise around tell-dont-ask as it may lead to getting rid of all query methods, even when they simplify collaboration.
  • Others believe that including assertions mixes the responsibilities, which leads to a bloated page object.

Page Object Return Other Page

  • If you navigate to another page, the initial page object should return another page object for the new page.
  • In general, page object operations should return fundamental types (strings, dates) or other page objects.

On navigation:

  • Common advice is that page objects should create other page objects in response to navigation.
  • Some practitioners prefer page objects to return a generic browser context. The test then decides which page object to create based on the test flow.

Page Component Objects

  • A page object doesn’t need to represent the entire page.
  • The same principles for page objects apply to “Page Component Objects”.
  • A page object wraps an HTML page or fragment, providing an API that hides the underlying HTML.
  • It’s essential to have only one place in your test suite with knowledge of the HTML structure of a particular page or part.

Naming:

  • The term “page object” may be misleading.
  • A better term might be “panel object”, but “page object” is the accepted term.

Example:

Page Component Objects in Selenium

Implementation Notes

  • Page objects should hide the details of the WebDriver instance.
  • Methods on the PageObject should return other PageObjects.
  • This approach models the user’s journey through the application.
  • If the relationship between pages changes, updating the method’s signature will cause the tests to fail.

Considerations:

  • There’s a debate on whether a page should know the flow of the next page.
  • Different results for the same action might need different methods.

In summary:

  • Page objects encapsulate details of the UI structure, hiding them from tests.
  • Some people use “Screen” instead of “Page” in App testing.

Reference

  1. TellDontAsk - Martin Fowler’s article discussing the principles of Tell, Don’t Ask.
  2. GetterEradicators - Martin Fowler’s view on the trend of eliminating getter methods.
  3. EmbeddedDocument - Martin Fowler’s perspective on objects that transform input information.
  4. Page Object’s return type - Details about how a page object should handle navigation and its return types.
  5. Page Component Objects in Selenium - Detailed documentation about page component objects from Selenium.
  6. Page Object vs. Panel Object - Martin Fowler’s thoughts on the naming of “page objects”.
  7. TwoHardThings - Martin Fowler’s take on the challenges of naming and cache invalidation.