Project
Playwright TypeScript Framework: Production-Style Browser Automation
A Playwright + TypeScript automation framework built and validated against a live public application, with API-driven test data and CI quality gates.
Key highlights
- Built against a live public application, not mock scenarios
- Page Object Model with API-based state seeding
- Accessibility scanning via axe-core, left intentionally failing to surface real bugs
- Sharded CI pipeline (lint → smoke → regression) with Allure reporting
Description#
A production-style test automation framework using Playwright and TypeScript, deliberately built against a live public application rather than sandboxed demo pages. The guiding principle behind the framework is that every decision — selectors, retries, wait strategy — is grounded in something actually inspected on a live site, not assumed.
Key Features#
- Page Object Model: Reusable page components with parameterized locators, kept close to what’s actually in the live DOM.
- API-Layer Integration: Test setup seeds state directly through the application’s API endpoints instead of re-driving the UI for every precondition, keeping tests fast and focused on the behavior under test.
- Data Factories: Faker-backed data generation alongside static reference data, so tests aren’t brittle against hardcoded fixtures.
- Accessibility Scanning: axe-core integration checks for WCAG violations — and is intentionally left failing where it finds them, rather than muted, so the framework surfaces real application bugs instead of hiding them.
- Code Quality Tooling: Type-aware ESLint, Prettier, and Husky pre-commit hooks keep the test codebase itself held to production standards.
- Environment Management: Config-driven
baseURLresolution across QA/staging/production.
Example Scenarios#
- Checkout Flow: Search → cart → payment, including simulated card-decline handling.
- Admin Panel: Login-gated CRUD operations exercised end-to-end.
CI/CD Pipeline#
A progressive quality-gate pipeline runs on GitHub Actions: lint → smoke tests → sharded regression across multiple browsers, with results published as Allure reports alongside HTML/JUnit output.
The 3 failures shown above aren’t flakiness — they’re the accessibility suite doing its job: a genuine color-contrast violation (4.25:1 against a required 4.5:1) on a live page, caught by axe-core and left failing rather than muted.
Usage Scenarios#
- Regression Testing: Sharded execution keeps full regression runs fast enough for every merge.
- Accessibility Auditing: Continuous axe-core scanning catches WCAG regressions as part of normal test runs.
- New Project Bootstrap: A reference implementation for teams standing up Playwright automation with real CI discipline from day one.