Project Case Study
Spectarum / Playwright Automation Framework
Quality Engineering Infrastructure
A type-safe, declarative automation framework that treats quality engineering as infrastructure: reusable, scalable, and wired for reliable product delivery. Two layers — an API framework with typed adapters, CRUD builders, schema validation and lifecycle cleanup, and a frontend layer for UI automation.
Overview
Spectarum is a type-safe, declarative Playwright framework that treats quality engineering as infrastructure rather than as a pile of test scripts.
It is one codebase with two layers. The API layer came first and carries most of the depth: typed adapters, declarative CRUD builders, schema validation, and automatic lifecycle cleanup. The frontend layer was added to close the gap between that robust API automation and the fragile UI testing sitting next to it.
They are not separate projects. Both layers live in the same repository, share one playwright.config.ts, and authenticate through the same global setup — so a UI test can seed its state through the API layer instead of clicking its way there.
- Layers, one codebase
- 2
- Playwright projects
- 7
- Boilerplate reduction (UI forms)
- 70-90%
- Platforms: admin + mobile
- 2
Deep Dive · v2.0 · stable
API Framework
Typed adapters and API services, declarative CRUD builders, runtime param resolvers, schema validation with readable diagnostics, lifecycle cleanup of created records, dependency fixtures, extra action suites, and module scaffolding.
Deep Dive · v1.0 · beta
Frontend Framework
Declarative form filling for complex CRUD flows: conditional fields, checkbox and iframe handling, retries and custom validation, resilient role/label/testId locators, and page objects that seed their state through the API layer.
What It Solves
Test automation decays when every suite re-implements the same plumbing. Each module ends up with its own login, its own request wrappers, its own hand-written CRUD cases, and its own static IDs that break the moment the environment is reseeded.
Spectarum removes that repetition by making a test a declaration of what a module is, not a script of what to click or call. A module describes its schema, its invalid cases, and its endpoints; the framework generates and runs the CRUD suite around it.
One Codebase, Two Layers
The split is by test folder, not by repository. A single playwright.config.ts defines the projects for both layers, and the global setup writes one token store that both read from.
playwright.config.ts auth global setup
│ │
│ tokens.json
│ (api + frontend)
▼ ▼
┌───────────────────────────────────────────┐
│ api/ api-admin api-merchant │
│ api-auth api-mobile │
│ api-e2e │
├───────────────────────────────────────────┤
│ frontend/ frontend-admin │
│ frontend-merchant │
└───────────────────────────────────────────┘API Layer — How a Test Is Built
A spec calls its module's schema builder, which configures a CrudTestBuilder. The builder produces a suite that runs view, create, update, and delete handlers against a typed module API class through a platform adapter.
Because the suite owns the lifecycle, records created during a run are tracked and cleaned up afterwards, and dependent records can be created or reused and injected as params.
spec file ↓ module schema builder ↓ CrudTestBuilder → CrudTestSuite ↓ view / create / update / delete handlers ↓ adminAdapter | mobileAdapter ↓ module API class ↓ BaseApi / ReadOnlyApi / WriteAndReadApi
Frontend Layer — Declarative Forms
The frontend layer exists because the API automation was solid while UI coverage was missing or fragile. Rather than duplicating platform concepts, it reuses the same admin and merchant adapters for authentication and data seeding.
UI work is expressed as field declarations passed to fillForm — types, selection strategies, conditional fields, and validation — instead of imperative click-and-type sequences.
Engineering Decisions
- Declarative over imperative: a module declares its shape; the framework derives the tests. Adding coverage is a schema change, not a new script.
- Typed end to end: generic API services and typed adapters mean a wrong module or field is a compile error rather than a runtime 404.
- Runtime resolution over fixtures-on-disk: retrieve, view and update resolve real IDs from list or data-table responses, so suites survive a reseeded environment.
- Cleanup as a framework concern: the lifecycle manager tracks created records, so tests do not leave debris for the next run.
- Shared auth across layers: one global setup issues both API and frontend tokens, which is what makes API-seeded UI tests practical.
Maturity
The two layers are deliberately at different stages. The API framework is on its second major version and is the one in daily use. The frontend layer is beta — usable, and not yet production hardened.
Both are documented in full — the links above go to the working documentation, not to a summary.
Explore More
Other Case Studies
Enterprise Healthcare Platform
Dentra
A clinic platform built around one fully isolated deployment per customer, and the reference implementation that ZothKit was extracted from.
Enterprise Property Operations Product
Atlas
A real-estate operations platform where the commercial model lives inside the transactions: plan limits, add-ons and capability tiers enforced under row locks rather than checked on a billing page.