A framework is an engineering product
A test framework should make tests easier to understand, execute, maintain, diagnose, and scale. It should separate business/test intent from technical interaction where practical.
Reference architecture
Test Cases / Scenarios
↓
Business / Domain Actions
↓
Page / API / Service Objects
↓
Drivers / Clients / Adapters
↓
Configuration + Data + Utilities
↓
Application / Services
Cross-cutting: Logging • Assertions • Reporting • CI
Responsibilities by layer
| Layer | Responsibility |
|---|---|
| Tests | State what behaviour is being validated. |
| Business/domain | Reusable meaningful actions. |
| Page/API/service | Technical interface interactions. |
| Data/config | Inputs, environment config, test builders, secrets handling. |
| Reporting | Actionable evidence and diagnostics. |
Anti-patterns
- Hard-coded credentials and URLs
- Locators scattered through every test
- Shared mutable state
- Sleep-based timing
- Assertions hidden inside generic helpers
- No framework ownership
Keep architecture proportional
Do not over-engineer early. Start with clear boundaries and reliable execution. Add abstraction when it solves a repeated maintenance problem.