Easy Testing Laravel Package

Getting Started

Install the package via Composer: composer require --dev symplify/easy-testing. Despite being archived, it provides minimal boilerplate reduction out-of-the-box. Begin by extending Symplify\EasyTesting\PHPUnit\TestCase in your test classes to inherit shared setup logic (e.g., container bootstrapping, fixture management). For Laravel-specific needs, combine it with Laravel’s native traits like RefreshDatabase—this package doesn’t replace them but complements them. Run ./vendor/bin/phpunit and verify basic tests execute; check phpunit.xml for snapshot-related configuration if using snapshot assertions.

Implementation Patterns

• Use TestCase as a base class to centralize setUp()/tearDown() logic (e.g., resetting singleton state, mocking shared clients).
• Leverage SnapshotTestCase for deterministic assertions on dynamic outputs: assertMatchesSnapshot($result) for JSON, HTML, or CLI output. Ideal for regression testing of view rendering or API responses.
• When testing service classes, extend KernelTestCase to bootstrap Laravel’s service container reliably—then inject dependencies directly via $this->app->make(Service::class).
• Combine with Laravel’s DatabaseTransactions or RefreshDatabase traits explicitly (e.g., use RefreshDatabase, TestCase;) since this package doesn’t override Laravel’s DB cleanup behavior.
• For large test suites, define snapshot path environment variables (SNAPSHOT_DIR=tests/Snapshots) in phpunit.xml to keep snapshots organized.

Gotchas and Tips

• Archive Risk: No active maintenance means no Laravel 11+/PHP 8.4+ compatibility guarantees. Copy critical traits (e.g., TestCase) locally if your project’s longevity depends on this functionality—e.g., paste the trait into tests/TestCase.php and maintain it yourself.
• Snapshot Path Quirks: Snapshots fail silently if the SNAPSHOT_DIR path doesn’t exist. Pre-create tests/Snapshots/ and ensure write permissions. Use assertStringMatchesSnapshotFile() only for static fixtures—avoid for time-sensitive outputs.
• Trait Conflicts: Avoid using TestCase and Laravel’s CreatesApplication together—stick to KernelTestCase as the base if both container bootstrapping and DB interactions are needed.
• Dependency Confusion: If using PHPStan orpest, confirm no method signature mismatches (e.g., setUp() overrides) between this package and your primary testing stack. Run ./vendor/bin/phpstan analyse after setup to catch static analysis errors early.
• Debugging Snapshots: Run tests with --testdox to see snapshot file names (e.g., ✔ My feature creates snapshot [foo_bar.test]). Compare mismatches manually—phpunit won’t auto-updated broken snapshots.