Product Decisions This Supports
- QA/quality-gate roadmap item: Turns "are all our endpoints tested?" from a manual audit into an automated, repeatable CI signal. Route-level coverage is a concrete, defensible definition-of-done increment for API work — cheap to adopt, easy to explain to stakeholders.
- Definition of Done for new endpoints: Adds a policy decision ("no route ships without a test that touches it") that is enforceable in the pipeline rather than in code review culture.
- Build vs. buy vs. fork: The underlying capability — enumerate routes, cross-reference against tests that exercise them — is a ~200-line internal script. Buying/consuming this package is a "buy" only in the sense of near-zero acquisition cost; the real decision is whether to vendor a fork rather than depend on a 1-star, 0-dependent package. Decide explicitly: adopt as dependency vs. copy the logic in-house.
- Refactor and migration safety: Useful tripwire when moving controllers, renaming routes, or consolidating an API surface — surfaces endpoints that silently lost test coverage during restructuring.
- Legacy estate triage: A fast inventory of untested public routes in an older Symfony app, feeding a prioritization list for hardening work (public/unauthenticated routes first, internal/admin later).
- Framework mismatch is a decision input, not a footnote: This is a Symfony bundle, not a Laravel package. If the product is Laravel, this specific artifact does not apply — the equivalent is a thin custom command built on
route:list plus code-coverage intersection, or an existing Laravel coverage tool. Treat this as a pattern to copy, not a dependency to install.
When to Consider This Package
Consider it when:
- The application is Symfony, and your team is already comfortable pinning and occasionally patching small third-party bundles.
- You have a functioning test suite and CI; this adds a gate, not a foundation. It is not useful on a codebase with near-zero tests.
- Route count is large enough that manual endpoint audits are expensive (roughly 30+ routes, or growing fast).
- You want a smoke-level invariant — "every route was reached at least once" — and understand it is not a behavioral or contract guarantee. A route can be "tested" by a request that asserts nothing.
- You can accept early-stage dependency risk: 1 star, 0 dependents, single-maintainer provenance, recent and possibly not-yet-stable release history. Mitigate by pinning the version, vendoring, or forking under your org.
Look elsewhere when:
- The stack is Laravel, Slim, Laminas, or anything non-Symfony — the bundle is not applicable; build the equivalent check internally.
- You need vendor support, an SLA, security-response commitments, or a maintainer who will respond to issues.
- Your entry points aren't HTTP routes (GraphQL, queue consumers, CLI commands, webhooks) — the coverage model won't reflect your real surface.
- You already enforce meaningful coverage thresholds or mutation testing; route-hit counting adds little and can create a false sense of safety.
- Policy forbids low-adoption or unvetted dependencies, or the org can't absorb the maintenance if the project is abandoned.
Assessment against signals: opportunity score ~38 and overall score ~16.8 indicate a narrow but real niche use case with weak adoption evidence. Treat it as a pattern reference implementation first, a pinned dependency second, and a strategic platform commitment never.
How to Pitch It (Stakeholders)
To executives: A small, free tool that automatically verifies every API endpoint in our Symfony service has at least one test exercising it. Cost is roughly a day of engineering to wire into CI; it catches endpoints that shipped untested — a common source of production incidents and security exposure. The risk is vendor maturity: the project is young with essentially no adoption, so I recommend we pilot it as a reference implementation, pin the version, and keep the option to maintain a fork internally rather than treating it as a strategic dependency.
To engineering: It enumerates the router's routes and fails the build when one is never hit by the test suite. That's a narrow invariant — it proves reachability, not correctness — so it complements, and does not replace, coverage, contract, or mutation testing. Integration is a CI step; expect to read the source (it's small and MIT-licensed) and to fork if it stalls. Also flag clearly: this is a Symfony bundle; if the team is on Laravel, we implement the same check ourselves in ~a day rather than importing it.
Recommendation: Pilot on one Symfony service, timeboxed, with the gate set to warn-only for the first two sprints before making it blocking. Revisit as a hard dependency only if the project shows maintenance activity and we've confirmed we can fork it comfortably.