Testa PHP-kod: PHPUnit och Pest

Kort sagt: PHPUnit är standardverktyget för att testa PHP-kod automatiskt; Pest är ett ramverk som bygger på det med kortare skrivsätt. Aktuell är PHPUnit 13 (sedan februari 2026, från PHP 8.4), Pest finns i version 5. Automatiska tester stänger inga säkerhetsluckor i själva PHP, men de gör uppdateringar planerbara: Efter PHP2Shell och före supportslutet för PHP 8.2 den 31 december 2026 är det den avgörande fördelen.

Varför testa PHP-kod?

För ledningen går nyttan att sammanfatta i en mening: Tester gör ändringar billigare och säkrare. Ett automatiskt test kontrollerar på sekunder om en funktion fortfarande gör det den ska, till exempel om en varukorg räknar rätt eller om en inloggning avvisar felaktiga lösenord. Utan tester kontrollerar en människa det för hand, eller ingen alls.

Skillnaden blir särskilt tydlig vid uppdateringar. Måste PHP uppdateras med kort varsel på grund av en kritisk lucka tvekar många driftansvariga, eftersom de fruktar fel i butiken eller kundportalen. Med en testsvit körs uppdateringen först i en testmiljö, testerna visar problem, och därefter går det live.

PHPUnit: standarden för PHP-tester

PHPUnit kommer varje år i februari i en ny huvudversion. Varje version kräver en lägsta PHP-version och får ungefär två års felrättningar. Enligt phpunit.de gäller:

Tabellen visar ett praktiskt samband: Ett projekt som fortfarande använder PHPUnit 10 körs oftast också på en gammal PHP-version. Testverktyg och PHP-version bör höjas tillsammans. PHPUnit installeras vanligtvis via Composer som utvecklingsberoende.

Ett första test med PHPUnit

Ett test är en klass som ärver från PHPUnit\Framework\TestCase. Testmetoder är publika och börjar med test, alternativt markerar man dem med attributet #[Test]. Exemplet testar en enkel funktion för prisberäkning:

<?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));
    }
}

Data provider levererar flera fall för samma test. Enligt PHPUnits dokumentation måste den vara publik och statisk. Beräkningen sker i cent som heltal, så att inga avrundningsfel uppstår av flyttal. Sviten körs med ./vendor/bin/phpunit om PHPUnit har installerats via Composer.

Pest: samma bas, kortare skrivsätt

Pest bygger enligt dokumentationen på PHPUnit. Tester skrivs som funktioner med it() eller test() och förväntningar med expect(). Pest 5 kräver PHP 8.4. Installationen enligt dokumentationen:

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

Samma test i Pests skrivsätt:

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

Befintliga PHPUnit-tester omvandlar pluginet pestphp/pest-plugin-drift i stor utsträckning automatiskt. Vilket skrivsätt ett team väljer är en smaksak; avgörande är att testerna körs regelbundet.

Vilka testtyper som är rimliga

1. Enhetstester: testar enskilda funktioner och klasser utan databas eller nätverk.
2. Integrationstester: testar samspelet med databas, filsystem eller gränssnitt.
3. Funktionstester via HTTP: anropar sidor och formulär som en webbläsare gör.
4. Säkerhetsregressionstester: fastlåser åtgärdade fel, till exempel att utdata maskeras med htmlspecialchars() eller att en inloggning misslyckas efter fel lösenord.
5. Smoke-tester efter driftsättningen: få snabba kontroller av om live-sidan svarar efter en uppdatering.

Som komplement till tester hittar den statiska analysen med PHPStan och Psalm fel utan att köra koden.

Tester som skyddsnät för uppdateringar och PHP2Shell

PHP2Shell har visat hur kort tiden mellan publicering och handlingstryck kan vara: Tillkännagivande den 20 oktober 2026, patchar den 21 oktober 2026, BSI (den tyska förbundsmyndigheten för informationssäkerhet) varningsnivå orange. Den som hade en testsvit kunde installera PHP 8.4.27 eller 8.3.36 i en testmiljö, köra testerna och gå live samma dag. Utan tester återstod ofta bara valet mellan en ogranskad uppdatering och en öppen lucka.

Nyttan är ännu större vid byte av huvudversion. För PHP 8.1 och äldre finns inga officiella uppdateringar längre, och PHP 8.2 tar slut den 31 december 2026, som sidan PHP End of Life förklarar. En testkörning mot målversionen visar tidigt vilka föråldrade funktioner som måste ersättas. Rimligt är en CI-pipeline som kör tester mot flera PHP-versioner, dessutom en titt på release candidates som PHP 8.6.0, men aldrig i produktion.

Hur hjälper PHP SOS konkret?

Vid migrering från PHP 8.1 och äldre och vid löpande uppdateringar stöder vi så här:

• Bedöma beståndet: Vilka tester finns, vilka PHP- och PHPUnit-versioner körs, var saknas tester för kritiska flöden?
• Skapa en minimitäckning: Tillsammans med ert utvecklingsteam eller er byrå säkrar vi inloggning, formulär och beställningsflöden med tester.
• Testa uppdateringar: Nya PHP-versioner körs först i en testmiljö mot sviten.
• Dokumentera resultatet: Ni får testresultat och versionslägen som bevis för patch- eller migreringssteget.

Vanliga frågor

Källor

• PHPUnit
• Pest
• php.net: PHP-versioner som stöds