Pyrameter Laravel Package

Product Decisions This Supports

• Test-strategy investment (build the right tests, not just more tests): Pyrameter answers "what kind of tests do we have?" — a question coverage tools can't. It classifies the suite and reports a shape (e.g., "Integration Mountain"), turning a vague engineering complaint ("our tests are slow and flaky") into a named, trackable problem you can put on a roadmap.
• Roadmap and quality OKRs: Gives you a metric for quality initiatives — "reduce integration tests from 60% to 30% of suite, hold unit coverage" — that is measurable release over release, not a one-off refactor with no before/after.
• Build vs. buy: The measurement layer is a single MIT-licensed dev dependency versus weeks of building a custom test-taxonomy dashboard. Buy (adopt) the measurement; spend engineering effort on the actual test rebalancing, which is the part that creates value.
• CI gate / definition of done: Usable as an advisory or blocking check in PR pipelines, giving product and engineering a shared, objective bar for "test suite health" rather than a subjective review comment.
• Due diligence and onboarding: Useful when inheriting a codebase — acquisitions, vendor packages, a new squad taking over a legacy Laravel app, or evaluating a framework upgrade where the team leans too heavily on slow end-to-end tests.
• Release-risk and cycle-time conversations: Shapes correlate with CI duration and flakiness; the report gives you evidence when negotiating capacity for test remediation against feature delivery.

When to Consider This Package

• Consider it when: you run PHPUnit on a PHP/Laravel codebase with a non-trivial suite; your engineers already distinguish unit vs. integration vs. E2E tests by directory, naming convention, or attributes so classification is possible; CI already executes the suite (near-zero marginal cost); and CI wall-clock time or flaky-test noise is a recurring complaint in retros.
• Strongest fit when: the suite is visibly top-heavy, teams are debating whether to invest in test refactoring, and you need a cheap, credible, objective artifact to settle the debate.
• Look elsewhere or defer when: there's no PHPUnit in the stack, the suite is small enough that shape is meaningless, or you require vendor support, SLAs, or a proven adoption base — 9 stars, 0 dependents, and a single-maintainer profile mean this is a "convenience dependency," not a platform commitment.
• Adoption guardrails: pin the version, isolate it to the require-dev side, treat it as advisory in CI for the first quarter, and confirm license (MIT) and PHP/PHPUnit version constraints against your matrix before rollout.
• Skip if you already have an equivalent signal from a broader quality platform, or if the team won't act on the output — a shape report nobody reads is pure ceremony.

How to Pitch It (Stakeholders)

For executives: Pyrameter is a free, MIT-licensed PHPUnit extension that measures the shape of our test suite and prints a one-screen report in CI. It costs essentially nothing to adopt and gives us a defensible, recurring metric for engineering quality — the kind of number we currently lack when we're asked whether the codebase is getting healthier. It surfaces over-reliance on slow, flaky integration tests, which is a direct driver of release cycle time.

For engineering: One dev dependency, no test rewrites. It classifies existing tests, prints an ASCII pyramid alongside the PHPUnit output, and can flag shape violations in CI. Low blast radius — pin it, run it advisory first, drop it if it doesn't earn its place. MIT means we can fork if the project stalls.

Honest risk framing: This is an early-stage, single-maintainer package with minimal community traction. That's acceptable for a dev-only measurement tool with no production runtime exposure, but it should not become a hard release gate or a load-bearing part of our quality narrative until we've validated it for a quarter. Recommend: pilot on one service, evaluate signal quality, then decide on broader rollout.