Layered Architecture for UI Automation Testing: Component, Page, Business Logic, and Test Case Layers

Background

Two to three years ago I wrote some articles on UI automation, covering design principles, page segmentation, and common design patterns. However, I never described the layering concept in detail, so I am adding it now based on recent project experience.

Previous Design

The classic pattern in UI automation is the Page Object Model, where each page is encapsulated as a class containing element locators, and test cases interact with the page through this class.

This model was created about 20 years ago based on the front‑end development practices of that time. Front‑end technologies have evolved dramatically, making the original pattern less suitable for current UI automation projects, so I have made some improvements.

Improved Design

Component Layer

Modern front‑end frameworks provide a component library concept to encapsulate common UI elements for reuse across pages, avoiding duplicate development and keeping visual style consistent.

In a typical front‑end project there is a component directory containing reusable components such as button, input, dropdown, and link, each with its own logic and CSS.

Because all pages use the same component definitions, any change in the component library instantly affects every page, which can break UI automation scripts. To mitigate this, UI automation projects also create a component layer that encapsulates element locators and common operations.

Example of a simple button component before a change:

<button> 确定 </button>

After the front‑end team modifies the component, the markup becomes:

<button>
    <span> 确定 </span>
</button>

Previously a test could locate the button with a text‑based XPath, but the change breaks that locator. By adding a component layer, the locator logic is centralized and can be updated in one place.

Page Layer

The page layer is similar to the traditional Page Object Model: each page is represented by a class that defines its elements and actions. The difference is that element location is delegated to the component layer.

All element locators inside the page class call the component layer, and the page class can also expose higher‑level page actions. This promotes code reuse and isolates test cases from UI changes.

Code reuse: many test cases share the same logic, reducing maintenance effort.

Stability: when page elements change, only the component or page layer needs updating.

Business Logic Layer

Each module has a service file that encapsulates complex business workflows spanning multiple pages, such as creating a workflow that requires filling out several configuration pages, submitting, and then polling for a final status.

This layer sits above the page layer and provides reusable functions for test cases, preventing duplication of lengthy multi‑page sequences.

Because different modules depend on each other (e.g., a data‑center module needs data synchronized from external sources before other modules can be tested), each module should expose its business‑logic services to others.

Test Case Layer

The test case layer remains lightweight; it simply calls the business‑logic layer (and occasionally the page layer) to execute tests, keeping test scripts concise.

Conclusion

These layered designs—component, page, business logic, and test case—help make UI automation more maintainable, resilient to front‑end changes, and easier to scale across large projects.