- What is Festing and how does it speed up Laravel tests?
- Festing is a development-only Laravel package that bundles testing helpers and assertions for PHPUnit, aiming to make unit and feature tests faster and more expressive. Its premise is that Laravel's per-test application re-bootstrapping is the dominant cost in a suite, so it amortizes or skips part of that lifecycle work. It plugs into Laravel's standard Illuminate\Foundation\Testing\TestCase flow rather than replacing PHPUnit. Because it hooks framework internals like createApplication and refreshApplication, treat it as a performance experiment rather than a drop-in guarantee.
- How do I install Festing in a Laravel project?
- Install it as a dev dependency with composer require --dev dees040/festing, then either swap your base TestCase or apply the package's trait. Setup is intentionally minimal, which is why it is cheap to trial on a throwaway branch. Do not add it to production requirements. Confirm the resolved version against your pinned Laravel and PHPUnit versions before committing anything.
- Which Laravel and PHPUnit versions does Festing support?
- The package targets Laravel's standard testing lifecycle, but the README does not document a clear compatibility matrix. Internal test-lifecycle APIs changed materially across Laravel 8 through 11 and PHPUnit 9 through 11, so a version mismatch is a hard stop. Verify support for your exact pinned PHP, Laravel, and PHPUnit versions before evaluating speed. If no supported combination is documented, read the source to confirm which internals it touches.
- Does Festing work with Pest?
- Pest runs on top of PHPUnit but wraps TestCase bootstrapping in its own way, so support cannot be assumed. The package hooks test lifecycle internals such as createApplication and refreshApplication, and Pest may alter when those run. If your suite is Pest-based, validate explicitly with a full run before relying on any speedup. A native PHPUnit suite is the safer starting point for a pilot.
- Is Festing safe with RefreshDatabase and database transactions?
- This is the main risk: a speed package that shares or reuses the application instance across tests changes isolation semantics by construction. Feature tests depending on RefreshDatabase, transaction rollback, queue and event fakes, authenticated session state, and container rebinding are the most likely to be affected. Silent false greens are worse than a slow suite, so prove behavioral equivalence rather than assuming it. Re-run the identical suite multiple times and diff pass/fail results and test ordering before adopting.
- Can Festing be used with parallel test execution like --parallel or ParaTest?
- Unverified. Parallel runners frequently break packages that make assumptions about shared state or a single application instance per process. If your CI uses --parallel or ParaTest, test that exact combination explicitly or disqualify the package. Do not assume locally observed speedups carry over to a parallel CI container.
- Should Festing be a require-dev dependency only?
- Yes. Festing is testing infrastructure and belongs in require-dev so it never reaches the production runtime or production autoload path. Its architectural footprint in the application is intentionally minimal because of this. Keep it out of production images and deployment artifacts, and scope it to CI and local development.
- How much faster will my Laravel test suite actually be with Festing?
- The README claims more than a 100% speedup, but that is not a measurement of your suite. Baseline your current wall-clock duration, per-class p50 and p95 timings, total test count, and flake rate, then run the identical suite three times on a branch with the package applied. Set an explicit decision gate, such as at least 30% reduction on the full suite with zero pass/fail deltas. If the gate is not met, discard it.
- Does Festing work with a custom base TestCase or custom bootstrappers?
- Not guaranteed. Any suite that wraps TestCase in its own base class, uses custom bootstrappers, or overrides setUp and tearDown needs explicit validation first. Because Festing hooks framework internals rather than a stable public contract, wrappers can change when those hooks fire. Audit how your base class initializes the container before assuming drop-in fit.
- Is Festing actively maintained, and should I adopt it or vendor the technique?
- Signals are weak: around 36 stars, a low composite score, and a single-maintainer profile suggest it is unlikely to track Laravel and PHPUnit changes promptly. Confirm the license and maintainer responsiveness to issues before depending on it. The source is small enough to audit and vendor in-house, which is the cheapest risk mitigation available. Given the maturity signals, reimplementing the technique in your own base TestCase is often the more realistic outcome than adopting the dependency outright.