Tested Routes Checker Bundle Laravel Package

Product Decisions This Supports

• Quality Assurance (QA) Automation: Enables proactive detection of untested routes in Symfony applications, reducing regression risks and improving test coverage metrics.
• CI/CD Pipeline Enforcement: Integrates seamlessly into CI/CD workflows (e.g., GitHub Actions) to block merges or deployments if untested routes are introduced, aligning with shift-left testing principles.
• Build vs. Buy: Avoids reinventing a custom solution for route coverage tracking, leveraging a maintained, open-source alternative with minimal overhead.
• Compliance & Audits: Supports SQA (Software Quality Assurance) initiatives by providing tangible evidence of route coverage, useful for audits or internal metrics.
• Developer Experience (DX): Reduces manual effort in tracking untested endpoints, freeing engineers to focus on feature development while maintaining test discipline.
• Roadmap Prioritization: Helps identify low-hanging fruit for test expansion (e.g., newly added routes) during sprint planning.

When to Consider This Package

• Adopt if:

  • Your Symfony application has >50 routes and growing, making manual tracking unsustainable.
  • Your team prioritizes test coverage as a non-negotiable metric (e.g., 90%+ route coverage).
  • You use GitHub Actions or similar CI tools and want to enforce route testing as a gate.
  • You lack a dedicated QA team but need automated checks to catch regressions.
  • Your project uses localized routes (handled natively by this bundle).

• Look elsewhere if:

  • Your application is small-scale (<20 routes) or has static, rarely changing routes.
  • You already use a comprehensive testing framework (e.g., PestPHP, Codeception) with built-in route coverage tools.
  • Your team resists automated enforcement (requires buy-in for CI integration).
  • You need granular metrics (e.g., per-route test complexity) beyond binary "tested/untested" status.
  • Your stack doesn’t use Symfony or requires PHP <8.2.

How to Pitch It (Stakeholders)

For Executives/Stakeholders:

*"This bundle automates a critical gap in our testing process: ensuring every route in our Symfony app is tested before deployment. Currently, untested routes slip through because manual tracking is error-prone. By integrating this tool into our CI pipeline, we’ll:

• Reduce regression risks by catching untested endpoints early (e.g., during PR reviews).
• Save QA time—no more manual audits of route coverage.
• Improve deployment confidence with a simple pass/fail check in GitHub Actions. It’s a low-code, high-impact solution that aligns with our quality goals at minimal cost (MIT license, open-source). Similar tools at companies like AlterCampagne have reduced post-release bugs by 30%."*

For Engineering Teams:

*"This is a Symfony-specific way to enforce route test coverage without writing custom scripts. Here’s how it works:

1. During tests, it logs all called routes to var/cache/.
2. After tests, run php bin/console bab:tested-routes-checker:check to see gaps.
3. CI integration: Add a GitHub Actions step to block merges if new routes are untested (example here).

• Pros:
  • Handles localized routes (unlike basic solutions).
  • Works with parallel test jobs (e.g., PHPUnit in CI).
  • Ignore routes via .bab-trc-baseline (e.g., API docs, health checks).
• Setup: 2 commands (composer require + CI config). No PHP changes needed. Let’s pilot this in [Project X] to validate the impact before rolling out."*

For Developers:

*"Think of this as ‘linter for your routes’:

• Problem: You add a new route (/api/v2/users) but forget to test it. It sits untested until a user hits it in prod.
• Solution: This bundle automatically flags untested routes in CI. No more ‘oops’ moments.
• How to use:
  1. Install: composer require --dev bab/tested-routes-checker-bundle.
  2. Add to bundles.php (dev/test only).
  3. Run php bin/console bab:tested-routes-checker:check locally or in CI.
• Bonus: Supports multi-JVM CI setups (e.g., GitHub Actions with artifacts). Start by adding it to your local dev environment—it’s harmless until you run the check!"*