Weave Code
Pest Laravel Package
pestphp/pest
Pest is an elegant PHP testing framework with a clean, expressive syntax built on PHPUnit. Write readable tests with higher-order expectations, datasets, and architecture testing, plus first-class Laravel support.
The elegant PHP Testing Framework.
Frequently asked questions about Pest
- What is Pest PHP and how does it work with Laravel?
- Pest is an elegant PHP testing framework built on top of PHPUnit, adding an expressive, minimal API for writing tests. For Laravel projects, the pestphp/pest-plugin-laravel package binds the Laravel base TestCase and helpers such as RefreshDatabase and HTTP/console testing utilities. Pest is installed as a development dependency, so it does not ship into the production runtime artifact.
- How do I install Pest in a Laravel project?
- Install it with Composer using composer require --dev pestphp/pest pestphp/pest-plugin-laravel, then run Pest's init command to create the tests/Pest.php conventions file. After that you can run your existing test suite unchanged because Pest honors phpunit.xml and PHPUnit behavior. This keeps the adoption path low-risk and easy to roll back by removing the dev dependency.
- Is Pest compatible with my existing PHPUnit tests?
- Yes. Pest is a superset of PHPUnit and honors phpunit.xml, PHPUnit attributes, mocks, and data providers. You can install Pest and execute the existing PHPUnit suite without refactoring, which lets you compare pass/fail parity and wall-clock time before committing to any migration. The real migration cost is usually custom PHPUnit extensions, listeners, or base TestCase logic rather than ordinary tests.
- Which PHP and Laravel versions does Pest v5 support?
- The exact minimum PHP version and Laravel support band for Pest v5 are defined by its Composer constraints and release notes, so verify them against your supported matrix before pinning. Because Pest releases frequent minors and major versions, the team should name an owner for the version pin. Do not assume support matches your stack without checking the package constraints.
- Does Pest add production risk or ship to production?
- No. Pest is a development-time dependency only, installed with require-dev, and it never ships into the runtime artifact or adds production attack surface. It has no bearing on deploy topology, request path, or SLA. However, a dev dependency still executes in CI with access to tokens and secrets, so it belongs in your dependency-review and allowlist workflow.
- How does Pest Test Impact Analysis work and is it safe as a quality gate?
- Pest v5's --tia feature uses test impact analysis to reduce the tests run, but it depends on a coverage driver such as PCOV or Xdebug and on fingerprints that include the PHP minor version. Stale caches, a PHP bump, or a missing coverage driver can produce false-green results, which is the most dangerous failure mode for a quality gate. It should never be the only job that runs before merge; keep a full-suite job or combine TIA with other checks.
- Can Pest run tests in parallel or shard across CI runners?
- Yes, Pest supports parallel testing and sharding, and those features are relevant when suite runtime and shard count make the ROI material. Recent patch notes have addressed parallel and sharding edge cases, including shard filters matching out-of-partition classes, --shard with --parallel exit codes, and ParaTest worker temp directories. Pin at or above a version that contains the sharding filter fix and validate the CI CPU budget before relying on TIA or parallel runs.
- How hard is it to migrate from PHPUnit to Pest?
- The migration is usually low-risk because Pest runs on PHPUnit as its assertion and attribute substrate, so existing PHPUnit tests can run unchanged. Start with a short spike: install Pest, run the suite, and compare pass/fail parity and wall-clock delta. Then refactor incrementally, prioritizing custom PHPUnit extension, listener, or base TestCase code because that is the real migration cost.
- Is Pest actively maintained and what are the upgrade risks?
- Pest is mature and actively maintained, but it has moved through v2, v3, v4, and v5 in a compressed window and ships frequent minor releases. Every major version is code-touching, so treat major upgrades as scheduled engineering work rather than passive composer update. The project is MIT licensed with no commercial SLA and a visibly concentrated maintainer footprint, so plan ownership and upgrade windows accordingly.
- Should we standardize on Pest only or allow mixed Pest and PHPUnit tests?
- Mixed Pest and PHPUnit is feasible because Pest is a superset and honors PHPUnit configuration, attributes, mocks, and data providers. A mixed approach lowers migration friction, while Pest-only maximizes the expressive API and developer experience. The team should decide the long-term standard explicitly and document it so new tests do not drift between styles.
Weaver
How can I help you explore Laravel packages today?