PHP-code testen: PHPUnit en Pest

Kort gezegd: PHPUnit is het standaardgereedschap om PHP-code automatisch te testen; Pest is een daarop voortbouwend framework met een kortere schrijfwijze. Actueel is PHPUnit 13 (sinds februari 2026, vanaf PHP 8.4), Pest ligt in versie 5 voor. Automatische tests dichten geen beveiligingslekken in PHP zelf, maar ze maken updates plannelijk: na PHP2Shell en vóór het einde van de ondersteuning van PHP 8.2 op 31 december 2026 is dat het doorslaggevende voordeel.

Waarom PHP-code testen?

Voor de directie laat het nut zich in één zin vatten: tests maken wijzigingen goedkoper en veiliger. Een automatische test controleert in seconden of een functie nog doet wat ze moet doen, bijvoorbeeld of een winkelwagen goed rekent of een login onjuiste wachtwoorden weigert. Zonder tests controleert een mens dat met de hand, of niemand.

Het verschil wordt vooral duidelijk bij updates. Moet PHP vanwege een kritiek lek op korte termijn worden bijgewerkt, dan aarzelen veel beheerders uit vrees voor fouten in de webshop of het klantenportaal. Met een testsuite draait de update eerst in een testomgeving, tonen de tests problemen en gaat het daarna live.

PHPUnit: de standaard voor PHP-tests

PHPUnit verschijnt elk jaar in februari in een nieuwe hoofdversie. Elke versie veronderstelt een minimale PHP-versie en krijgt ongeveer twee jaar foutcorrecties. Volgens phpunit.de geldt:

De tabel toont een praktisch verband: een project dat nog PHPUnit 10 gebruikt, draait meestal ook nog op een oude PHP-versie. Testgereedschap en PHP-versie horen samen te worden verhoogd. PHPUnit wordt gewoonlijk via Composer als ontwikkelafhankelijkheid geïnstalleerd.

Een eerste test met PHPUnit

Een test is een klasse die erft van PHPUnit\Framework\TestCase. Testmethoden zijn publiek en beginnen met test; alternatief markeert men ze met het attribuut #[Test]. Het voorbeeld test een eenvoudige functie voor prijsberekening:

<?php declare(strict_types=1);

use PHPUnit\Framework\Attributes\DataProvider;
use PHPUnit\Framework\TestCase;

final class BruttopreisTest extends TestCase
{
    public static function preise(): array
    {
        return [
            'Normalsatz'   => [10000, 19, 11900],
            'Ermäßigt'     => [10000, 7, 10700],
            'Null bleibt Null' => [0, 19, 0],
        ];
    }

    #[DataProvider('preise')]
    public function testBruttopreisInCent(int $netto, int $satz, int $erwartet): void
    {
        $this->assertSame($erwartet, bruttopreis($netto, $satz));
    }
}

De data provider levert meerdere gevallen voor dezelfde test. Volgens de PHPUnit-documentatie moet hij publiek en statisch zijn. Er wordt in centen als geheel getal gerekend, zodat er geen afrondingsfouten door kommagetallen ontstaan. De suite wordt uitgevoerd met ./vendor/bin/phpunit, als PHPUnit via Composer is geïnstalleerd.

Pest: dezelfde basis, kortere schrijfwijze

Pest is volgens de documentatie op PHPUnit gebouwd. Tests worden als functies met it() of test() geschreven en verwachtingen met expect(). Pest 5 vereist PHP 8.4. De installatie volgens de documentatie:

composer remove phpunit/phpunit
composer require pestphp/pest --dev --with-all-dependencies
./vendor/bin/pest --init

Dezelfde test in Pest-schrijfwijze:

<?php
it('berechnet den Bruttopreis zum Normalsatz', function () {
    expect(bruttopreis(10000, 19))->toBe(11900);
});

Bestaande PHPUnit-tests zet de plugin pestphp/pest-plugin-drift grotendeels automatisch om. Welke schrijfwijze een team kiest, is een kwestie van smaak; beslissend is dat tests regelmatig draaien.

Welke testsoorten zinvol zijn

1. Unittests: testen afzonderlijke functies en klassen zonder database of netwerk.
2. Integratietests: testen het samenspel met database, bestandssysteem of koppelingen.
3. Functionele tests via HTTP: roepen pagina's en formulieren aan, zoals een browser dat doet.
4. Beveiligings-regressietests: leggen verholpen fouten vast, bijvoorbeeld dat uitvoer met htmlspecialchars() wordt geëscaped of dat een login na een onjuist wachtwoord mislukt.
5. Smoke-tests na de deployment: enkele snelle controles of de live-site na een update reageert.

Als aanvulling op tests vindt de statische analyse met PHPStan en Psalm fouten zonder de code uit te voeren.

Tests als vangnet voor updates en PHP2Shell

PHP2Shell heeft laten zien hoe kort de tijd tussen publicatie en handelingsdruk kan zijn: aankondiging op 20 oktober 2026, patches op 21 oktober 2026, BSI-waarschuwingsniveau oranje (BSI: de Duitse federale dienst voor informatiebeveiliging). Wie een testsuite had, kon PHP 8.4.27 of 8.3.36 in een testomgeving doorvoeren, de tests laten draaien en nog dezelfde dag live gaan. Zonder tests restte vaak alleen de keuze tussen een ongecontroleerde update en een open lek.

Nog groter is het nut bij een wissel van hoofdversie. Voor PHP 8.1 en ouder zijn er geen officiële updates meer, en PHP 8.2 eindigt op 31 december 2026, zoals de pagina PHP-end-of-life uitlegt. Een testrun tegen de doelversie toont vroeg welke verouderde functies moeten worden vervangen. Zinvol is een CI-pipeline die tests tegen meerdere PHP-versies draait, plus een blik op release candidates zoals PHP 8.6.0, echter nooit in productie.

Hoe helpt PHP SOS concreet?

Bij de migratie van PHP 8.1 en ouder en bij lopende updates ondersteunen wij als volgt:

• Bestand beoordelen: Welke tests zijn er, welke PHP- en PHPUnit-versie draaien, waar ontbreken tests voor kritieke processen?
• Minimale dekking realiseren: Samen met uw ontwikkelteam of bureau beveiligen wij login, formulieren en bestelroutes met tests.
• Updates testen: Nieuwe PHP-versies draaien eerst in een testomgeving tegen de suite.
• Resultaat documenteren: U ontvangt testresultaten en versiestanden als bewijs voor de patch- of migratiestap.

Veelgestelde vragen

Bronnen

• PHPUnit
• Pest
• php.net: ondersteunde PHP-versies