Weave Code
Testing For Laravel Laravel Package
roundly-consulting/testing-for-laravel
A Laravel testing package that provides practical helpers and assertions to streamline feature and unit tests. It reduces boilerplate and makes it easier to write clear, reliable tests for Laravel applications, from HTTP interactions to application behavior.
Dev-only test machinery for Laravel packages and apps: base test cases, a structural migration-order pin, and Pest expectations that can always fail
Frequently asked questions about Testing For Laravel
- How do I install roundly-consulting/testing-for-laravel?
- It is a dev-only dependency, so install it with composer require --dev roundly-consulting/testing-for-laravel. No service provider registration or config publishing step is required, so there is nothing to wire into your application bootstrap. After that, extend the provided base test case in your package test suite and declare your migration sources.
- What is PackageTestCase in this Laravel testing package?
- PackageTestCase is a base test class that owns the database lifecycle for downstream package test suites. It plugs into Laravel's migration runner and the configured database connection rather than into application runtime code, giving each test consistent schema isolation. You extend it in each of your packages and override hooks such as migrationSources() to point at that package's migrations.
- How do I tell PackageTestCase which migrations to run?
- Override the migrationSources() hook on your test case and return the paths or sources that should be migrated for the suite. This keeps each package in control of its own schema instead of depending on the host application's migrations. If the list is empty, no migration work happens at all.
- What does keepsMigratedSchema() actually do?
- It is a schema-reuse optimization that lets the suite keep an already-migrated schema instead of rebuilding it for every test. It only engages when something was actually migrated, and it is explicitly a no-op when migrationSources() is empty. That means hand-built fixture tables are still dropped between tests, so do not rely on cross-test residue.
- Why did my package database tests start passing after upgrading to 1.6.1?
- 1.6.1 changed behavior for suites with an empty migrationSources(): they previously failed every database test with 'no such table: migrations' and now pass. If you worked around the symptom by adding a dummy migration source or a migrations table fixture, re-check that scaffolding and remove it in the same pull request. The release notes describe no removed API or signature change, so the bump itself is low risk.
- Does this package work with both Pest and PHPUnit?
- The package ships Pest expectations alongside PHPUnit-compatible base test cases, so both runners are covered. Verify against the specific Pest and PHPUnit versions your estate uses, since the engine and runner matrix is not spelled out in the release notes. Start with one pilot package before rolling it out more widely.
- What are the Pest expectations that can always fail used for?
- They let you assert that a code path fails on purpose, which is useful for negative testing, for proving that a guard or validation actually triggers, and for smoke-testing your own test harness. Instead of writing throwaway failing tests, you express the intent as a reusable expectation. This keeps intentionally-failing cases readable and consistent across suites.
- How does the migration-order pin work?
- It is a structural test that pins the order of your migrations, so an accidental reorder or a migration inserted in the wrong place fails in CI rather than surfacing later as confusing schema drift. Treat it as a cheap regression guard for your migrations directory. If you intentionally reshuffle migrations, update the pin in the same change.
- Does it work with Laravel parallel testing?
- Each parallel worker gets its own database, and the drop-per-test reset interacts with worker-level schema setup. Confirm that per-worker bootstrapping still holds when you enable --parallel, and run the pilot suite on every database engine in your matrix rather than only the default. Capture before-and-after suite runtime to see whether the schema snapshot path is actually engaging.
- Is this package safe to ship to production?
- No, it belongs in require-dev. There is no service provider or production wiring, so it never loads in a deployed application. Keeping it out of require avoids shipping test scaffolding and keeps your production blast radius at effectively zero.
Weaver
How can I help you explore Laravel packages today?