Laracon US 2024

Overview of the Pest 3.0 Evolution Testing in the PHP ecosystem transformed when Pest PHP first arrived, bringing a functional, human-readable syntax to a world dominated by verbose object-oriented boilerplate. With the release of version 3.0, the framework moves beyond mere test execution and into the realm of full-spectrum development workflow. Created by Nuno Maduro, Pest 3.0 addresses the psychological and practical gaps in the testing process: managing unfinished work, maintaining architectural integrity across teams, and verifying that tests actually provide the security they claim to offer. These features aren't just aesthetic upgrades; they represent a shift toward making the test suite the central source of truth for a project's health and roadmap. Prerequisites To get the most out of this tutorial, you should have a solid grasp of the following: * **PHP 8.2+**: Modern PHP features are central to the framework's performance. * **Basic Testing Concepts**: Familiarity with assertions, mocks, and the red-green-refactor cycle. * **Laravel Framework**: While Pest works with any PHP project, its integration with Laravel is seamless and highly optimized. * **Composer**: Knowledge of package management to handle updates and dependencies. Key Libraries & Tools * Pest PHP: The core testing framework focused on developer experience. * **Linear**: A task management tool often used alongside Pest for tracking project progress. * **Sublime Text**: The editor used for demonstration, though VS Code or PhpStorm are equally supported. * **PHPUnit**: The engine under the hood that Pest abstracts into a more elegant syntax. Integrated Task Management One of the most friction-heavy parts of development is the context switch between a code editor and a project management tool like Linear or GitHub Issues. Pest 3.0 bridges this gap by turning your test suite into a task manager. Previously, developers used the `todo()` method to mark a test for future implementation. Now, you can assign these tasks directly to team members and link them to specific issue IDs. Implementation Walkthrough You can chain methods to define the owner and the reference point for any pending test. This keeps the technical debt visible right where the code lives. ```php it('allows users to edit their profile') ->todo(assignee: 'Nuno Maduro', issue: 11); ``` When you have several related tasks, you can avoid repetition by grouping them within a `describe` block. By chaining `todo` to the block itself, every test within that scope inherits the status. ```php describe('User Management', function () { it('can create a user'); it('can delete a user'); })->todo(assignee: 'Taylor Otwell', issue: 22); ``` When a feature is complete, simply swap `todo()` for `done()`. This keeps the metadata—who built it and why—intact within the codebase. If the test fails months later, the original context is instantly available to whoever is debugging. Architectural Presets for Code Consistency Architectural testing ensures that your project's structure remains consistent, preventing "leaky abstractions" or improper dependencies. Pest 3.0 introduces **Presets**, which allow you to apply hundreds of industry-standard rules with a single line of code. This is a massive improvement over manually writing granular rules for every new project. Using the Presets Instead of writing individual expectations, you call the `arch()->preset()` method. For example, the `php` preset ensures you aren't using dangerous functions like `eval()` or leaking environment details via `phpinfo()`. ```php // tests/ArchTest.php arch()->preset()->php(); arch()->preset()->security(); ``` For Laravel developers, the `laravel` preset is particularly powerful. It enforces resourceful controller naming conventions and ensures that exceptions correctly implement `Throwable`. ```php arch()->preset()->laravel(); ``` Pest also caters to different coding philosophies with `strict` and `relaxed` presets. The `strict` preset might demand `final` classes and private methods, while `relaxed` allows for more flexibility, ensuring that whichever style you choose remains consistent across the entire application. Mutation Testing: The Truth About Coverage Traditional code coverage is often a deceptive metric. It tells you which lines of code were *executed* during a test, but it doesn't prove that your tests would actually catch a bug if those lines were changed. **Mutation Testing** solves this by intentionally breaking your code (creating "mutants") and seeing if your tests fail. If the code changes but the tests still pass, the mutant has "escaped," and your test quality is poor. Running a Mutation Test To run mutation testing, use the `--mutate` flag in your terminal. Pest will analyze your source code, apply mutations (like changing a `public` method to `protected` or removing a database save call), and rerun the tests. ```bash ./vendor/bin/pest --mutate ``` If Pest removes a critical line—such as `$user->save()`—and your tests still pass, the output will show a diff of the mutation. This highlights exactly where you need to add more meaningful assertions rather than just "hitting" the line to satisfy a coverage percentage. Syntax Notes & Best Practices * **Higher-Order Assertions**: Pest encourages chaining methods like `->expect()->toBe()` for readability. * **Parallel Execution**: When running mutation testing, always use the `--parallel` flag. Mutation testing is computationally expensive because it reruns the suite many times; parallelization keeps the feedback loop fast. * **Context over Coverage**: Don't aim for 100% code coverage; aim for a high mutation score. The latter proves that your assertions are actually verifying logic. Tips & Gotchas * **Zero Breaking Changes**: Upgrading from Pest 2.0 to 3.0 is a simple `composer update`. The team prioritized backward compatibility despite the major version bump. * **Filtering**: When debugging mutation failures, use filters to run mutations against a specific file to save time: `pest --mutate --filter=PasswordController`. * **Avoid Over-assignment**: While Task Management is powerful, don't let your test suite become a dumping ground for every minor idea. Use it for tasks that require a specific technical implementation.