# Rewrite Tests Pest > Use when rewriting existing tests to PEST syntax. Follows project conventions, ensures DRY principles, uses data providers, maintains 100% coverage, and verifies test functionality. - Skill: `tomevault-io/rewrite-tests-pest-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/rewrite-tests-pest-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/rewrite-tests-pest-2/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/rewrite-tests-pest-2 --- **Constraint:** - Read project.mdc file - First, load all the rules for the cursor editor (.cursor/rules/.*mdc). **Steps:** - For tests that do not use PEST syntax, I want you to rewrite them in PEST syntax. - Never generate the covers() method! - Follow the rules for writing tests. - Create deterministic every time! - Arrange-act-assert pattern, error cases first - Before writing tests, always analyze the abstractions that will be used in the tests and always use helper methods if it simplifies the code. - **Never use the `describe()` function** in tests. Write tests at the top level using `it()` / `test()` only; do not wrap them in `describe()` blocks. - If there are any "shared" helper functions such as `bindSparkpostMailerNever($this->app);`, I want all these functions to be defined in the Pest.php file. - If the PEST test requires calling a method that is in an abstract class, use the notation `test()->methodName()`. - Test classes must be `final`; use only local variables inside tests. - Remove unnecessary mocks. - Mock only external API communication services or if you need to simulate exceptions. Do not use constructor mocking! - In tests, avoid reflection; use mocks instead (even partial ones, if they are effective and easy to read). - If the test requires persisted Laravel Eloquent rows, create them only via `Model::factory()` (see `@.cursor/rules/laravel/architecture.mdc` Testing). For other test data, follow `@.cursor/rules/php/standards.mdc`. Never mock it or circumvent this in any other way! - In Laravel factories, do not set attributes whose values are already defined by a database column default unless the test explicitly needs a different value (see `@.cursor/rules/laravel/architecture.mdc` Schema defaults and Testing). - In Laravel tests, dispatch queue jobs only via `JobClass::dispatch(...)` (see `@.cursor/rules/laravel/architecture.mdc` Testing — Dispatching jobs in tests). - Tests must not contain conditions (e.g., `if`, `switch`); split conditional logic into separate test cases instead. - Correct DRY, use data providers, and try to write tests as simply as possible. - After creating or modifying tests, check that they are not flaky. - Analyze the created tests and all tests that are similar and can be simplified using data providers, then modify them. - Tests must have 100% coverage. - If new database migrations exist in the current branch, run them (`php artisan migrate`) before running tests. - After writing the tests, verify that they are functional and follow the rules. - After generating or modifying tests, verify that all new tests comply with the testing rules in `@.cursor/rules/php/standards.mdc`. Check mock usage specifically: mock only external services (HTTP clients) or to simulate exceptions; remove any constructor mocks, unnecessary mocks, or mocks that can be replaced with real service logic. **After completing the tasks** - If according to @.cursor/skills/test-like-human/SKILL.md the changes can be tested, do it! ## Output Humanization - Use [blader/humanizer](https://github.com/blader/humanizer) for all skill outputs to keep the text natural and human-friendly. --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/pekral) — claim your Tome and manage your conversions.