Test Laravel Package

Technical Evaluation

Architecture Fit

• Modern PHP Alignment: The #[Test] attribute plugin leverages PHP 8.1+ attributes, which aligns with Laravel’s adoption of attributes (e.g., #[Route], #[Middleware]). This reduces friction for teams already using modern PHP features.
• Test Discovery Paradigm: Replaces naming conventions (e.g., test* prefixes) with declarative attributes, improving test organization and reducing false positives in test discovery.
• Laravel Compatibility: While Testo is not Laravel-native, its plugin-based architecture allows integration via custom adapters (e.g., service providers, Artisan commands). The attribute system is agnostic to Laravel’s testing helpers, enabling hybrid use cases.
• Isolation: Supports private method testing (via #[Test] on private methods), a feature lacking in Laravel’s PHPUnit integration by default.

Integration Feasibility

• Low Coupling with Laravel: The plugin does not enforce Testo as the sole testing framework; it can run alongside PHPUnit/Pest if Testo is used for specific test suites. However, full integration requires adopting Testo’s test runner.
• Attribute Conflicts: Potential conflicts with PHPUnit/Pest’s #[Test] attributes. Mitigation:
  • Use namespace isolation (e.g., \Testo\Test vs. \PHPUnit\Framework\TestCase).
  • Leverage Testo’s exclusion rules in configuration.
• Laravel-Specific Gaps: Testo lacks native support for Laravel features like:
  • RefreshDatabase trait.
  • Artisan command integration (e.g., php artisan test).
  • Database transactions for Laravel’s DatabaseMigrations. Workaround: Build custom Testo extensions or adapters.
• Configuration Overhead: Requires additional setup (e.g., service provider, Artisan commands) compared to PHPUnit’s zero-configuration Laravel integration.

Technical Risk

Key Questions

1. Strategic Fit:

   • Does Testo’s plugin ecosystem (e.g., mocking, assertions) provide critical advantages over PHPUnit/Pest for Laravel’s use cases?
   • Is the team willing to accept Laravel-specific gaps (e.g., missing RefreshDatabase) or invest in custom solutions?

2. Adoption Strategy:

   • Should Testo replace PHPUnit entirely, or be used for specific test suites (e.g., unit tests)?
   • How will CI/CD pipelines transition from phpunit.xml to Testo’s configuration?

3. Laravel-Specific Needs:

   • Are there non-negotiable Laravel features (e.g., queue testing, notifications) that Testo cannot support without extensions?
   • Will the team contribute back to Testo for Laravel compatibility, or maintain a fork?

4. Developer Experience:

   • How will the team balance Testo’s syntax (e.g., assertThat()) with Laravel’s existing testing patterns?
   • What training or documentation will be needed to onboard developers?

5. Long-Term Viability:

   • Is the php-testo/testo team responsive to issues, or should the team prepare for self-maintenance?
   • What is the exit strategy if Testo fails to gain traction (e.g., migration back to PHPUnit)?

Integration Approach

Stack Fit

• PHP Version: Requires PHP 8.1+ (attributes support). Laravel 9+ is fully compatible.
• Testing Stack:
  • Primary: Testo (with testo/test for attribute discovery).
  • Secondary: PHPUnit/Pest (for hybrid use cases or gradual migration).
• Laravel Components:
  • TestCase: Extend Testo\TestCase or wrap in a Laravel-specific base class (e.g., LaravelTestCase).
  • Service Container: Register Testo services in AppServiceProvider to integrate with Laravel’s DI.
  • Artisan: Create a custom testo command to mirror Laravel’s phpunit command.
  • Database: Use Testo’s transactional tests or build a Laravel adapter for RefreshDatabase.
• CI/CD: Replace phpunit calls with ./vendor/bin/testo or a custom Artisan command.

Migration Path

1. Phase 1: Proof of Concept (PoC)

   • Install Testo alongside PHPUnit:

     composer require --dev testo/testo testo/test phpunit/phpunit
     

   • Convert 1–2 test files to use #[Test] and Testo’s syntax.
   • Benchmark:
     • Test execution speed.
     • Feature parity (e.g., HTTP assertions, database transactions).
     • Developer ergonomics (e.g., assertion syntax).

2. Phase 2: Hybrid Integration

   • Configure Testo to coexist with PHPUnit:
     • Use namespace isolation (e.g., \Tests\Unit\Testo vs. \Tests\Unit\PHPUnit).
     • Update composer.json to support both:

       "autoload-dev": {
         "psr-4": {
           "Tests\\Testo\\": "tests/testo/",
           "Tests\\PHPUnit\\": "tests/phpunit/"
         }
       }
       

   • Build a Laravel Service Provider:
     • Register Testo’s test case and listeners.
     • Bind Testo services to Laravel’s container.
     • Add a testo Artisan command alias. Example:

     // app/Providers/TestoServiceProvider.php
     public function register()
     {
         $this->app->singleton(TestoTestCase::class);
         $this->app->bind(TestoRunner::class, function ($app) {
             return new TestoRunner($app->make(TestoConfig::class));
         });
         $this->commands([
             new TestoCommand(), // Custom Artisan wrapper
         ]);
     }
     

   • Create a Testo Artisan Command:

     // app/Console/Commands/TestoCommand.php
     public function handle()
     {
         $runner = app(TestoRunner::class);
         $result = $runner->run();
         exit($result->exitCode());
     }
     

3. Phase 3: Full Adoption

   • Migrate all test files to Testo, starting with unit tests (lowest risk).
   • Replace Laravel’s phpunit.xml with Testo’s configuration (e.g., testo.php).
   • Deprecate PHPUnit after full migration or retain it for legacy tests.
   • Phase out hybrid setup once Testo supports all critical Laravel features.

Compatibility