Pest on the 5.x line: a PHP testing framework whose repository front page points elsewhere

Three 5.3 patch releases in fifteen days

Pest's default branch is 5.x, and the top of the README carries a banner announcing that Pest v5 is now available, with a link to the announcement at pestphp.com/docs/pest5-now-available. The release history shows how quickly that line is moving: v5.3.3 on 2026-10-18, v5.3.4 on 2026-10-27 and v5.3.5 on 2026-11-01. The most recent push to the repository landed on 2026-11-02, the day after the latest tag.

That pace is good news if you are waiting on a fix, and a cost if you run a large suite in CI. Three patch versions in roughly two weeks means a loose version constraint can pull a different Pest build between two pipeline runs. If a test starts failing without any change on your side, the first thing to compare is which 5.3.x release each run resolved, and the safest habit is to commit your lock file and upgrade on purpose.

The README is a signpost, not a manual

The repository README is around 170 words of project content. It states what Pest is in one sentence, points to the docs at pestphp.com, links the creator's YouTube, Twitch, X, LinkedIn, Instagram and TikTok accounts, thanks sponsors and names the license. There is no install command on the page, no sample test, no list of assertions and no description of the command-line runner.

For a reader this has a concrete consequence: you cannot evaluate Pest from GitHub alone. Anyone who lands on the repository from a search, or who reviews dependencies by reading upstream READMEs, has to leave for pestphp.com to learn how a test file looks or how the suite is started. The badges at the top of the README link to the package page on Packagist at packagist.org/packages/pestphp/pest, which is the distribution point the project itself references, so that is where to confirm the package name and published versions before adding it to a project.

AGENTS.md, .claude/ and .codex/ sit next to src/

The project description reads "The elegant testing framework for PHP developers and AI agents", and the file tree reflects the second half of that sentence. Alongside src/, tests/ and composer.json, the top level of the repository holds an AGENTS.md file and two directories named .claude/ and .codex/, plus a .hod/ directory and a .temp/ directory.

What those files contain is not explained on the README, and the one-line pitch is the only place the front page mentions agents at all. The verifiable reading is narrow: the maintainers keep agent configuration in the repository itself. Whether Pest offers anything specific to the coding agents in your own project, as opposed to the agents used to work on Pest, is a question the README leaves open. If the agent angle is the reason you are looking at Pest, the place to settle it is the documentation on pestphp.com, not the repository front page, and you should not assume agent-specific features exist until you find them described there.

PHPStan, Rector and Pint configuration in the package root

Pest's root directory is dense with code-quality configuration. There are four NEON files: phpstan.neon, phpstan-baseline.neon, phpstan-pest-extension.neon and a file simply called extension.neon. Next to them sit rector.php and pint.json, along with an .editorconfig. The presence of phpstan-baseline.neon tells you the project runs static analysis with a recorded baseline of accepted findings rather than a clean slate.

The file names suggest a split between configuration the project uses on itself and configuration meant to extend PHPStan for Pest code, but the README does not say which file is intended for consumers or how to include it. If your team runs PHPStan over its test directory and wants it to understand Pest test files, read those two extension files directly and check the docs before wiring either into your own phpstan.neon. Guessing which one to include risks either a missing extension or a duplicate one.

tests/ and tests-external/, with phpunit.xml as the suite config

The repository splits its own tests across two directories, tests/ and tests-external/, and the suite configuration at the root is a phpunit.xml file. Beside src/ there are also overrides/, stubs/, resources/ and bin/ directories. Their names indicate executable entry points, file templates and replacement code, but the README does not explain any of them.

This matters mostly to contributors and to anyone debugging a failure that originates inside Pest. When a stack trace points into the package, the code may live in src/ or in overrides/, and the split between internal and external tests means a reproduction case could belong in either place. CONTRIBUTING.md and RELEASE.md both exist at the top level, so the contribution process and the release procedure are written down in the repository, even though the README itself does not summarize them. Read CONTRIBUTING.md before opening a pull request rather than inferring the workflow from the directory layout.

Funding and attention run through one creator

Every personal link in the README points to Nuno Maduro, who is named as Pest's creator, and sponsorship is routed through his GitHub Sponsors page at github.com/sponsors/nunomaduro. The sponsor list is long: PhpStorm, CodeRabbit, SerpApi, Bento, CMS Max, Redberry, Typesense, Pixel and NativePHP are highlighted, followed by TestMu AI, Zapiet, LoadForge, Route4Me and Nerdify. The README credits those sponsors with funding Pest's development.

The upside is visible in the release cadence. The trade-off is concentration: the project's public identity, its funding channel and its outreach all run through one person's accounts. For most users that changes nothing day to day. For an organisation weighing a long-term dependency, it is a factor to note alongside the MIT license, which at least guarantees the code can be forked and maintained by others if that ever becomes necessary.

What you must read before adding it to a project

Because the README stops at a one-line pitch, several decisions cannot be made from it. It does not state a minimum PHP version, does not say which frameworks Pest integrates with, and does not describe how Pest coexists with an existing test suite. None of that means the answers are missing from the project; it means they are elsewhere.

The practical order is short. Open composer.json in the repository to see the PHP version constraint and the dependencies Pest pulls in, since that file is the binding statement of what your environment needs. Read the Pest v5 announcement linked from the README banner if you are coming from an earlier major version. Then check the Packagist page for the exact release you plan to pin, currently v5.3.5. Skipping these steps is how teams end up discovering a PHP version mismatch or an upgrade change in CI instead of during evaluation.

Editorial conclusion

Pest suits PHP teams who are comfortable taking their instructions from pestphp.com and tracking a fast patch cadence on the 5.x branch. Teams that expect requirements, install steps and examples in the repository itself will find a short README with sponsor links instead, so before adopting it read composer.json for the PHP and dependency constraints, read the Pest v5 announcement for upgrade notes, and pin the exact 5.3.x release you test against.

Frequently asked questions

Official sources

1. License: MIT
2. pestphp/pest on GitHub
3. Project website
4. README
5. Releases