Page Objects DRAFT

If you have WebDriver APIs in your test methods, You're Doing It Wrong. -- Simon Stewart.

What problem?

Brittle Unit Tests: Unit Tests interacting directly with HTML elements and WebDriver APIs are brittle and susceptible to UI changes.
Duplicate Code: Unit tests are prone to duplicating code to drive complex HTML widgets.

Encapsulation: Page Objects encapsulate the HTML and WebDriver API complexity
Page API: Page Objects expose an API that only deals with the services provided on the page
Reuse: the code to drive the page and widgets are encapsulated in one area. Changes to UI are handled in one spot.
BDD: Excellent fit for Cucumber tests

Public methods represent the services that the page offers
Try not to expose the internals of the page
A page object should not have any assertions. One exception might be when constructing the page, check the correct page is loaded.
Complex pages should be broken down into smaller page objects
When navigating return the page object for the next page
Pass the concrete widget test. If the concrete widget on a page changes the Page Object API should not change.
Avoid methods names that include the following words: click, type, getText, etc as these are most probably interacting with single elements
Remember, Page Objects are not about HTML elements and WebDriver APIs but about Application use cases.