Houd vast aan één testframework

Introductie

Hoewel Pest bovenop PHPUnit is gebouwd en de twee frameworks technisch compatibel zijn, brengt het mengen van beide teststijlen in hetzelfde Laravel-project onnodige complexiteit en verwarring met zich mee. Een consistente testaanpak waarbij je door je hele testsuite heen ofwel PHPUnit ofwel Pest gebruikt, wordt sterk aangeraden.

Waarom

• Verminderde cognitieve belasting: Teamleden hoeven maar één testsyntaxis en -aanpak te leren en te onthouden
• Eenvoudigere onboarding: Nieuwe ontwikkelaars die bij het project komen, hebben een eenvoudigere leercurve met één enkele, consistente teststijl
• Consistentie op de command line: Voorkom verwarring over welke test runner je moet gebruiken (vendor/bin/phpunit versus vendor/bin/pest)
• Betere onderhoudbaarheid: Consistente patronen maken het eenvoudiger om tests door de hele codebase heen bij te werken en te refactoren
• Vermijd compatibiliteitsproblemen: Sommige PHPUnit-annotaties (zoals @runTestsInSeparateProcesses) zijn niet compatibel met Pest
• Duidelijkere projectstandaarden: Eén enkel testframework stelt duidelijke verwachtingen voor alle bijdragers
• Vereenvoudigde CI/CD-pipelines: Geen noodzaak om meerdere test runners of speciale configuraties af te handelen

Geschikt voor

• Alle Laravel-projecten, ongeacht de omvang
• Teams met meerdere ontwikkelaars
• Projecten met langdurige onderhoudseisen
• Codebases waar consistentie en leesbaarheid prioriteit hebben
• Open-sourceprojecten waar externe bijdragers duidelijke richtlijnen nodig hebben

Minder geschikt voor

• Projecten die actief migreren van PHPUnit naar Pest (een tijdelijke gemengde toestand is acceptabel tijdens de overgang)
• Monorepo's waar verschillende packages legitieme redenen hebben om verschillende frameworks te gebruiken (hoewel consistentie ook hier over het algemeen beter is)

Omgaan met bestaande gemengde testsuites

Als je een project overneemt of momenteel hebt met gemengde PHPUnit- en Pest-tests, overweeg dan om te migreren naar één enkel framework:

Migratie naar Pest

Pest biedt verschillende tools om PHPUnit-tests te helpen converteren:

1. Drift Plugin (Automatisch):

composer require pestphp/pest-plugin-drift --dev
./vendor/bin/pest --drift

2. Laravel Shift (Semi-Automatisch):

   • Gebruik de Pest Converter-dienst
   • Geschatte tijdsbesparing: ~3 uur voor typische projecten
   • Handelt de meeste conversies automatisch af

3. Handmatige Migratie:

   • Converteer tests geleidelijk terwijl je aan gerelateerde features werkt
   • Gebruik Pest's compatibiliteitslaag tijdens de overgangsperiode
   • Zorg ervoor dat alle nieuwe tests het beoogde framework gebruiken

Migratie naar PHPUnit

Als je team de voorkeur geeft aan PHPUnit:

• Pest-tests kunnen handmatig worden herschreven als PHPUnit-testklassen
• Dit is doorgaans arbeidsintensiever dan migreren naar Pest
• Overweeg deze route als het team een sterke voorkeur heeft voor class-gebaseerd testen

Wat er geconverteerd wordt (PHPUnit naar Pest)

Bij het gebruik van geautomatiseerde conversietools:

• ✅ Lifecycle-methoden (setUp, tearDown) → Pest-hooks (beforeEach, afterEach)
• ✅ Testmethoden → Pest test()- of it()-functies
• ✅ Data providers → Pest-datasets
• ✅ Testgroepen → Pest group()-chaining
• ✅ PHPUnit-assertions → Pest-expectations (waar beschikbaar)

Belangrijk: Private hulpmethoden in testklassen worden functies, wat handmatige aanpassingen kan vereisen omdat ze toegang tot $this verliezen.

Uitzonderingen

Het enige scenario waarin het mengen van frameworks acceptabel is:

Tijdens Actieve Migratie: Een tijdelijke periode waarin je tests van het ene framework naar het andere converteert is acceptabel, maar zou moeten zijn:

• Time-boxed (stel een deadline voor voltooiing)
• Duidelijk gecommuniceerd naar het team
• Gedocumenteerd in de project-README of de bijdragerichtlijnen
• Geprioriteerd om de duur van de gemengde toestand te minimaliseren

Voorbeelden

❌ Slecht: gemengde testsuite

tests/
├── Feature/
│   ├── UserRegistrationTest.php    # PHPUnit class
│   ├── checkout_test.php            # Pest functional test
│   └── ProfileTest.php              # PHPUnit class
└── Unit/
    ├── calculate_discount_test.php  # Pest functional test
    └── OrderTest.php                # PHPUnit class

✅ Goed: consistente PHPUnit-testsuite

tests/
├── Feature/
│   ├── UserRegistrationTest.php
│   ├── CheckoutTest.php
│   └── ProfileTest.php
└── Unit/
    ├── DiscountCalculatorTest.php
    └── OrderTest.php

✅ Goed: consistente Pest-testsuite

tests/
├── Feature/
│   ├── UserRegistrationTest.php
│   ├── CheckoutTest.php
│   └── ProfileTest.php
└── Unit/
    ├── DiscountCalculatorTest.php
    └── OrderTest.php

Projectdocumentatie

Documenteer je gekozen testframework in je project:

In README.md of CONTRIBUTING.md:

## Testing

This project uses Pest for all tests. When writing new tests:

- Use `test()` or `it()` functions, not PHPUnit classes
- Run tests with `./vendor/bin/pest` or `php artisan test`
- Follow existing test patterns in the `tests/` directory

See [Pest documentation](https://pestphp.com/docs) for syntax reference.

Of voor PHPUnit:

## Testing

This project uses PHPUnit for all tests. When writing new tests:

- Extend `Tests\TestCase` for feature tests
- Extend `PHPUnit\Framework\TestCase` for unit tests
- Run tests with `./vendor/bin/phpunit` or `php artisan test`
- Follow PSR-4 naming conventions for test classes

See [PHPUnit documentation](https://docs.phpunit.de) for syntax reference.

Meer informatie

• Migreren van PHPUnit naar Pest
• Pest Converter door Laravel Shift
• Een PHPUnit-Testsuite Converteren naar Pest - Spatie
• Documentatie Pest Drift Plugin
• Laravel Testing Documentatie