Filter Laravel Package

Technical Evaluation

Architecture Fit

• Laravel Ecosystem Mismatch: The package is Testo-specific and lacks native Laravel integration (e.g., no support for Laravel’s TestCase, phpunit.xml, or Artisan test workflows). Laravel’s default testing stack (PHPUnit/Pest) already provides robust filtering capabilities (--filter, --group, --testdox-html), making this package a non-ideal fit unless:
  • The project explicitly requires Testo for legacy or performance reasons.
  • A custom test runner is being built on top of Testo’s core (e.g., for CI optimization).
• Use Case Alignment: The package excels at CLI-driven test filtering (e.g., --filter, --path), but Laravel’s testing is event-driven (e.g., TestCase lifecycle hooks, service container integration). This misalignment could lead to workarounds (e.g., custom Artisan commands) rather than seamless integration.
• Opportunity for Hybrid Workflows: Could supplement Laravel’s testing if used to pre-filter tests before passing them to PHPUnit/Pest (e.g., via a custom script or CI pipeline).

Integration Feasibility

• Core Functionality: The package’s filtering logic (name patterns, paths, suites, types, datasets) is technically feasible to integrate but requires:
  • Wrapper Layer: A custom Artisan command or service provider to bridge Testo’s CLI to Laravel’s console.
  • Test Runner Override: Modifying Laravel’s TestWorker or TestCase to delegate filtering logic to Testo.
• Dependency Risks:
  • Testo’s CLI Dependency: Laravel’s test workflow assumes PHPUnit/Pest; integrating Testo’s CLI would require manual orchestration (e.g., parsing Testo’s output for Laravel’s test reporters).
  • Autoloading Conflicts: Testo’s classes may clash with Laravel’s autoloader unless namespaced or isolated (e.g., in a Docker container).
• Laravel-Specific Gaps:
  • No support for Laravel’s test helpers (e.g., assertDatabaseHas, actingAs).
  • No integration with Laravel’s service container or migration testing.
  • No compatibility with Laravel’s test event system (e.g., testsStarted, testFailed).

Technical Risk

Key Questions for TPM

1. Strategic Alignment:

   • Why adopt Testo/filter when Laravel already supports PHPUnit/Pest filtering with less friction?
   • Is this part of a larger Testo migration (e.g., legacy system integration), or a one-off optimization?

2. Integration Scope:

   • Will this replace Laravel’s test runner, or supplement it (e.g., for specific test suites)?
   • Are there existing Testo tests that must be migrated to Laravel’s ecosystem?

3. CLI vs. Programmatic Needs:

   • Is filtering required via CLI flags (e.g., artisan testo:run --filter=UserTest) or programmatic hooks (e.g., TestCase::filter())?
   • Can Laravel’s existing filtering (e.g., @group, --filter) meet the same goals?

4. Team and Tooling:

   • Does the team have Testo expertise, or is this a greenfield integration?
   • Will this block IDE/test tooling (e.g., VS Code’s PHPUnit test explorer)?

5. Long-Term Viability:

   • Is Testo a temporary solution, or will it be actively maintained alongside Laravel?
   • Are there plans to contribute Laravel integrations to Testo, or fork the package?

6. Performance and CI Impact:

   • How does Testo’s filtering compare to PHPUnit/Pest in parallel test execution?
   • Will this reduce CI runtime, or introduce new dependencies (e.g., Docker for Testo isolation)?

Integration Approach

Stack Fit

• Primary Fit: Low for Laravel’s default stack. The package is Testo-centric and lacks:
  • Laravel’s TestCase integration.
  • phpunit.xml or Pest configuration support.
  • Artisan test command compatibility.
• Secondary Fit: Medium for:
  • Custom test runners (e.g., CI-optimized workflows).
  • Hybrid testing (e.g., using Testo for filtering + PHPUnit/Pest for assertions).
  • Legacy system migration (e.g., phasing out Testo while keeping its filtering logic).
• Alternatives:
  • PHPUnit: Native --filter, --group, and Laravel’s TestCase support.
  • Pest: Fluent filtering (tests()->filter()) with Laravel integration.
  • Custom Logic: Implement filtering in a TestCase trait or service provider.

Migration Path

Option 1: Hybrid Filtering (Low Risk)

1. Install Testo/filter as a dev dependency:

   composer require --dev testo/filter
   

2. Create a Custom Artisan Command to wrap Testo’s CLI:

   // app/Console/Commands/TestoFilter.php
   namespace App\Console\Commands;
   use Illuminate\Console\Command;
   class TestoFilter extends Command {
       protected $signature = 'testo:filter {filter?}';
       public function handle() {
           $filter = $this->argument('filter') ?? '';
           $command = "vendor/bin/testo run --filter={$filter}";
           $output = shell_exec($command);
           $this->output->write($output);
       }
   }
   

3. Use in CI/CD:

   # .github/workflows/test.yml
   - run: php artisan testo:filter "AuthTest"
   

4. Limitations:
   • No Laravel test helpers (e.g., assertDatabaseHas).
   • Output must be manually parsed for Laravel’s test reporters.

Option 2: Pre-Processing Filter (Medium Risk)

1. Generate a Filtered Test List:

   vendor/bin/testo run --list | grep "AuthTest" > filtered_tests.txt
   

2. Pass to PHPUnit:

   phpunit --test-list=filtered_tests.txt
   

3. Automate in a Script:

   # scripts/filter-and-run.sh
   FILTER=$1
   vendor/bin/testo run --list | grep "$FILTER" | phpunit --test-list=/dev/stdin
   

Option 3: Full Testo Integration (High Risk)

1. Replace Laravel’s Test Runner:
   • Extend Illuminate\Foundation\Testing\TestCase to use Testo’s runner.
   • Override runTest() to delegate to Testo’s core.
2. Migrate Assertions:
   • Replace Laravel’s helpers with Testo’s assertions (e.g., assertTrue() instead of assertDatabaseHas()).
3. Risks:
   • Breaking changes if Laravel’s test APIs evolve.
   • No community support for Laravel-specific issues.

Compatibility