December 5, 2023 ADC Team 6 min read

Test Frameworks: Architecture and Design Patterns

A poorly architected test framework quickly becomes a burden: fragile, hard to maintain, and abandoned by the team. Design patterns allow you to build robust frameworks that stand the test of time.

Key takeaways

Page Object Model (POM): the most widely used pattern — each page/component has a dedicated class; tests call business methods, never raw selectors
Screenplay Pattern (Serenity BDD): models tests as actors accomplishing tasks — more expressive than POM for complex BDD scenarios
Factory Pattern for test data: generates configurable objects with sensible defaults; combine with Faker for realistic, non-repetitive datasets
Anti-patterns to avoid: hardcoded selectors in tests, order-dependent tests, sleep() waits instead of explicit waits

Page Object Model (POM) — The Fundamental

POM is the most widespread pattern in UI automation. Each page or component of the application has a dedicated class that encapsulates its elements and actions. Tests never manipulate selectors directly — they call high-level business methods.

Advantage: A selector change only impacts one class, not all tests
Principle: Clear separation between "how we interact with the page" and "what we test"
Evolution: Combines well with the Factory pattern to instantiate pages

Screenplay Pattern — Evolved POM

The Screenplay Pattern (used in Serenity BDD) models tests as scenarios of actors who accomplish tasks through abilities. More verbose than POM, but more expressive for complex behavioural tests and BDD teams.

Factory Pattern for Test Data

Do not create your test objects by hand in every test. Use factories (or builders) that generate configurable objects with sensible default values. Combine with Faker for realistic data.

Strategy Pattern for Environments

To manage multiple environments (dev, staging, prod), the Strategy Pattern allows injecting configuration at runtime. Your tests remain identical — only the configuration strategy changes.

Recommended Project Structure

pages/ — Page Objects or components
tests/ — Tests organised by feature/domain
fixtures/ — Test data, factories
utils/ — Helpers (wait, scroll, screenshot)
config/ — Configuration per environment
reports/ — Test reports (gitignored)

Anti-Patterns to Avoid

Never hardcode selectors in tests. Avoid tests that depend on execution order. Do not duplicate navigation logic between tests — create helpers. Avoid fixed waits (sleep) in favour of explicit waits.

Master Test Architecture

Our Advanced Framework Design course covers POM, Screenplay, CI/CD and advanced patterns with practical use cases.

View the Test Frameworks course