Package Testing
Primary Goal
Prove package behavior with Pest 4/5, Orchestra Testbench, and the local tests/TestCase.php setup before or alongside implementation.
Workflow
- Start with TDD: write the smallest failing package test for the requested behavior, then implement the smallest change that makes it pass.
- Cover happy-path, unhappy-path, and edge-case behavior when the feature has meaningful failure modes.
- Prefer focused feature tests for package integration behavior and arch tests for broad constraints.
- Use
composer test:unit -- --filter ...while iterating,composer test:typeswhen type-sensitive tests or code changed, andcomposer testbefore finishing. - Keep real package tests in the suite and remove only throwaway tests that were explicitly created for local scaffolding experiments.
References
tests/TestCase.phptests/Pest.phptests/Feature/tests/Unit/tests/ArchTest.phpcomposer.jsonscripts
Examples
- Test config merge and config override by asserting default package config, then overriding the host config value in the Testbench app.
- Test publishable assets, migrations, views, lang files, or config by invoking vendor publish behavior and asserting the target path exists.
- Test routes with Testbench HTTP requests, commands with Artisan assertions, migrations with a SQLite test database, and workbench behavior after
composer buildwhen needed.
Anti-Patterns
- Deleting real package tests because they are inconvenient.
- Relying only on smoke tests when behavior needs assertions.
- Testing implementation details when observable package behavior is available.
- Keeping throwaway scaffolding experiment tests in the package test suite.