Page object model

The page object model is a structural pattern for user interface automation. Each screen, or each significant component, gets a class owning two things: how to locate its elements, and what a person can do with them. Tests then call methods on that object rather than addressing the page directly, so a test states that a user signs in and arrives at the dashboard instead of listing the fields it typed into and the button it pressed. Every selector for a given screen lives in exactly one file. The name predates the current generation of automation frameworks, though the principle it encodes has outlived each tool that popularised it.

The payoff is maintenance arithmetic. When a form is redesigned the change lands in one class instead of across every test that touched the form, which is the difference between a suite that survives a redesign and one quietly abandoned after it. That is the most common way automation projects fail commercially. It is rarely that the tests were hard to write; it is that an ordinary amount of product change made them more expensive to keep alive than to delete.

Applying it without over-engineering it

• Expose intent rather than widgets. A method that submits an order is useful; a method that clicks the submit button has only renamed the click.
• Keep assertions out of the object. The object knows how to operate the screen, and the test decides what ought to be true once it has.
• Return the next object where an action navigates, so a test reads as a route through the product rather than as a sequence of unrelated instructions.
• Resist building a class per URL out of duty. Shared components deserve their own objects, and a screen with three fields does not need a hierarchy above it.

Modern frameworks ship their own locator and fixture abstractions, so the ceremony of the pattern matters less than the rule underneath it: selectors belong in one place.