Loading
testparity.com
Structural test ownership and matched coverage as a release gate
A documentation-first CLI for structural test parity that verifies each source file has a belonging test, validates coverage ownership, and exposes matched coverage so teams can fail CI on weak per-file proof instead of trusting global coverage alone.
Tag
Developer Tools · Test Infrastructure
Duration
Ongoing
Role
Product framing · Documentation UX · CLI positioning
The site leads with the real testing problem: matched coverage, file ownership, and CI-grade output that makes weak structural proof visible before a release ships.
Core metric
Matched coverage
Format support
Parity + XML
Use case
CI release gate
◇ The problem
Where they were stuck.
Global test coverage can look healthy while the test that is supposed to own a file barely exercises it. Teams needed a clearer release gate that maps files to belonging tests, reads existing coverage artifacts, and flags when incidental suite execution hides weak file-level accountability.
◇ Our approach
How we shipped it.
- 01
Framed the product around the core conceptual shift: global coverage answers whether the suite touched enough code, while Parity answers whether the test that owns a file actually covered that file.
- 02
Built the public surface as a documentation-first onboarding path, showing quickstart, parity.yaml structure, matched-coverage thresholds, sample repos, and real CI-shaped output instead of abstract testing claims.
- 03
Positioned the CLI as ecosystem-friendly rather than framework-locked by leaning on what the source already supports: Parity JSON, PHPUnit XML, Clover, Cobertura, plugins, and samples across PHP, TypeScript, JavaScript, Laravel, AdonisJS, and Rust.
- 04
Made the output legible for code review and release gating, with named files, expected tests, per-rule failures, and ownership-focused reporting that teams can wire into existing pipelines without replacing their test runner.
◇ Stack
What it's made of.
PHPLaravel ZeroCoverage readersCLI release gatePlugin rulesVitePress docs
Next case study