Tested Routes Checker Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony Native Integration: The bundle is designed for Symfony applications (v6.4+, 7.3+, 8.0+), leveraging Symfony’s routing, dependency injection, and console components. This aligns perfectly with Laravel’s ecosystem if wrapped in a Laravel-compatible facade (e.g., via a custom bridge or Symfony microkernel integration).
• Route-Centric Focus: The package’s core functionality (tracking tested routes via HTTP calls) is highly relevant for Laravel, where route coverage is a common pain point in testing. Laravel’s route system (RouteServiceProvider, web.php, api.php) can be mapped to Symfony’s routing abstraction.
• Cache-Driven: Uses Symfony’s cache system (var/cache/...) to store route calls. Laravel’s storage/ or bootstrap/cache/ could serve as equivalents, requiring minimal adaptation.

Integration Feasibility

• Symfony Dependency Overlap: Laravel lacks Symfony’s Routing and HttpKernel components, necessitating:
  • A custom route collector to mirror Symfony’s RouteCollection.
  • A request interceptor (e.g., middleware) to log route hits during tests (similar to Laravel’s Testing facade).
• PHPUnit Integration: The bundle assumes PHPUnit for test execution. Laravel’s phpunit.xml and tests/ structure are compatible, but the bundle’s CLI command (bab:tested-routes-checker:check) would need a Laravel-specific facade (e.g., php artisan bab:check-routes).
• Localization Support: The bundle handles localized routes (e.g., _locale parameters). Laravel’s route localization (via Route::localization() or packages like spatie/laravel-localization) would require mapping to Symfony’s Route objects.

Technical Risk

• High Adaptation Effort: Rewriting Symfony-specific logic (e.g., RouteCollection, Route objects) for Laravel’s router (Illuminate\Routing\Router) is non-trivial but manageable with a wrapper layer.
  • Key Risks:
    • Route parameter extraction (e.g., named routes vs. URI patterns).
    • Middleware/guard interactions (Symfony’s Route objects include middleware; Laravel’s Route objects do not).
    • Cache storage location (var/cache/ → Laravel’s storage/framework/cache/).
• Testing Overhead: The bundle’s accuracy depends on all test requests being logged. Laravel’s Http::fake() or Testing::fake() might interfere; a custom TestRequestListener would be needed.
• CI/CD Complexity: The GitHub Actions example assumes Symfony’s artifact handling. Laravel’s CI (e.g., GitHub Actions, CircleCI) would need adjusted artifact paths (storage/ instead of var/cache/).

Key Questions

1. Route Granularity:
   • Does Laravel’s route system support the same level of route identification as Symfony (e.g., named routes with parameters)?
   • How are dynamic routes (e.g., {id}) handled in the bundle’s storage vs. Laravel’s route caching?
2. Middleware/Guard Coverage:
   • Will the bundle’s route checks account for middleware/route guards (e.g., auth, throttle) that might block certain routes during testing?
3. Performance Impact:
   • What is the overhead of logging every route hit during test execution? Could this slow down Laravel’s test suite significantly?
4. Baseline File Format:
   • The .bab-trc-baseline file ignores routes. How would this translate to Laravel’s test exclusions (e.g., ignoreRoutes() in phpunit.xml)?
5. Symfony-Specific Features:
   • Does Laravel support the same route attributes (e.g., _controller, _route) as Symfony? If not, how would the bundle adapt?
6. Artisan Command Integration:
   • How would the bab:tested-routes-checker:check command be exposed in Laravel (e.g., as a custom Artisan command or facade)?
7. Multi-Environment Support:
   • How would the bundle handle Laravel’s environment-specific routes (e.g., config('app.env')) or route caching differences?

Integration Approach

Stack Fit

• Laravel Compatibility:
  • Router: Replace Symfony’s RouteCollection with Laravel’s Router instance, adapting route parameter extraction.
  • Cache: Use Laravel’s FileCache or ArrayCache to store tested routes in storage/framework/cache/bab_tested_routes.
  • Console: Expose the checker as an Artisan command (php artisan bab:check-routes).
  • Testing: Integrate with Laravel’s Testing facade to intercept HTTP calls during test execution.
• Dependencies:
  • Symfony Components: Only symfony/routing and symfony/http-kernel are critical. These could be replaced with Laravel’s native classes or minimal polyfills.
  • PHPUnit: Laravel’s PHPUnit setup is compatible, but the bundle’s phpunit-bridge would need a Laravel-specific alternative (e.g., orchestra/testbench).

Migration Path

1. Phase 1: Proof of Concept
   • Create a Laravel wrapper package (e.g., bab/laravel-tested-routes-checker) that:
     • Extends Laravel’s Router to log route hits.
     • Replaces Symfony’s RouteCollection with a Laravel-compatible version.
     • Implements a custom Artisan command.
   • Test with a small Laravel app (e.g., laravel/laravel skeleton).
2. Phase 2: Core Functionality
   • Adapt the route storage logic to use Laravel’s cache.
   • Implement the baseline file (.bab-trc-baseline) as a Laravel config file (config/bab-trc.php).
   • Add middleware to ensure route logging works with Laravel’s test helpers.
3. Phase 3: CI/CD Integration
   • Update the GitHub Actions example for Laravel’s artifact paths.
   • Add support for parallel test jobs (e.g., PestPHP or PHPUnit parallelizer).
4. Phase 4: Advanced Features
   • Localization support (map Laravel’s route localization to Symfony’s format).
   • Middleware/guard awareness (extend Laravel’s Route object to include guard info).

Compatibility

• Laravel Versions: Target Laravel 10+ (PHP 8.2+) for alignment with Symfony 6.4+.
• Testing Frameworks: Primarily PHPUnit, but adapt for PestPHP (Laravel’s default).
• Route Service Providers: Ensure compatibility with Laravel’s RouteServiceProvider and API route groups.
• Cache Drivers: Support file, database, and redis cache drivers for flexibility.

Sequencing

1. Route Logging:
   • Modify Laravel’s Testing facade or create a TestedRoutesServiceProvider to log routes during tests.
2. Storage Layer:
   • Implement a TestedRouteStorage class using Laravel’s cache.
3. Artisan Command:
   • Build CheckRoutesCommand to compare stored routes against the baseline.
4. CI/CD Pipeline:
   • Integrate the command into Laravel’s test workflow (e.g., php artisan bab:check-routes in tests/Feature/RouteCoverageTest.php).
5. Localization/Middleware:
   • Add support for Laravel’s route attributes (e.g., middleware, name) in later iterations.

Operational Impact

Maintenance

• Dependency Updates:
  • Laravel’s router and cache systems are stable, but breaking changes (e.g., Laravel 11’s route system) may require updates.
  • Symfony components (if used) must be kept in sync with Laravel’s PHP version.
• Route Schema Changes:
  • Adding/removing routes in Laravel’s routes/ files will require updating the baseline or test suite.
• Test Suite Maintenance:
  • Developers must ensure all routes are tested; false negatives (e.g., untested routes) will trigger CI failures.

Support

• Debugging Untested Routes:
  • The bundle provides a CLI report, but Laravel’s route debugging tools (e.g., route:list) may need integration for deeper insights.
• False Positives/Negatives:
  • Routes blocked by middleware (e.g., auth) may appear untested. Documentation should clarify how to handle these cases.
• Community Support:
  • Limited dependents (0) and stars (12) suggest niche adoption. Laravel-specific support would rely on the wrapper package’s maintainers.

Scaling

• Large Route Counts:
  • The cache storage (bab_tested_routes_checker_bundle_route_storage) could grow large with thousands of routes. Laravel’s cache drivers (e.g., Redis) would mitigate this.
• Parallel Testing:
  • The GitHub Actions example supports parallel jobs. Laravel’s PestPHP or PHPUnit parallelizer would need similar artifact merging logic.
• Performance:
  • Route logging adds overhead during tests. Benchmark to ensure it doesn’t slow down the suite (e.g., >10% runtime increase).

Failure Modes

• Incomplete Route Logging:
  • If tests use Http::fake() or Testing::ignore(), routes may not be logged. Clear documentation is