- How do I migrate PHPUnit tests to Pest using this package?
- Use the `PEST_MIGRATION` rule set in your `rector.php` config. Run Rector with `--dry-run` first to preview changes, then apply it to your test files. The package handles common assertions like `assertEquals()` and converts them to Pest’s `expect()` syntax. Always review changes manually for edge cases.
- Which Laravel versions support this package?
- This package works with Laravel 10+ projects using Pest (v2, v3, or v4). For older Laravel versions, ensure your Pest version is compatible with the target Laravel release. The package itself has no Laravel-specific dependencies beyond Pest and Rector.
- Can I apply these rules selectively to specific test files?
- Yes, configure `withPaths()` in `rector.php` to target specific directories or files. For example, exclude legacy tests by adding `'--exclude=tests/legacy'` to your Rector command. Use `--dry-run` to validate the scope before full execution.
- What if Rector changes my test logic unintentionally?
- Start with `PEST_CODE_QUALITY` for safe, non-breaking improvements. For migrations, use `PEST_MIGRATION` but review changes carefully. Disable individual rules in `rector.php` if needed, like `->withSkip([SomeRule::class])`. Always test your suite after running Rector.
- Does this package work with Pest plugins like Browser?
- Yes, but some rules (e.g., `PEST_BROWSER`) require additional dependencies like `pestphp/pest-plugin-browser`. Check the [rules documentation](https://github.com/MrPunyapal/rector-pest/blob/main/docs/rules.md) for plugin-specific requirements. Install dependencies first with `composer require --dev pestphp/pest-plugin-browser`.
- How do I handle large test suites to avoid performance issues?
- Run Rector in parallel with `--parallel` or split your test suite into smaller batches. For CI/CD, cache results using tools like GitHub Actions’ `actions/cache`. Avoid running on the full suite in development unless necessary.
- What’s the difference between `PEST_CODE_QUALITY` and `PEST_MIGRATION`?
- `PEST_CODE_QUALITY` refactors existing Pest tests for better readability (e.g., chaining `expect()` calls, fixing static callbacks). `PEST_MIGRATION` converts PHPUnit-style tests to Pest syntax. Use `PEST_CODE_QUALITY` first for incremental improvements, then `PEST_MIGRATION` for full conversions.
- Will this break my existing Pest tests?
- Most rules are opt-in and backward-compatible. However, `PEST_MIGRATION` may alter test logic during PHPUnit-to-Pest conversions. Always run tests after applying rules and use `--dry-run` to preview changes. Start with a small subset of tests to validate safety.
- How do I integrate this with PHPStan or PestStan?
- This package includes PestStan-aligned fixes (e.g., static callback detection) but doesn’t require PestStan at runtime. For deeper static analysis, combine it with PestStan by installing both packages. The semantic architecture ensures compatibility without tight coupling.
- What if I need to upgrade Pest versions mid-project?
- Use `PestSetList::UP_TO_PEST_40` or similar version-specific sets to target your current Pest version. Avoid mixing sets (e.g., don’t apply v3→v4 + v2→v3 rules simultaneously). Check the [semantic architecture docs](https://github.com/MrPunyapal/rector-pest/blob/main/docs/semantic-architecture.md) for upgrade paths.