Testare il codice PHP: PHPUnit e Pest

In breve: PHPUnit è lo strumento standard per testare automaticamente il codice PHP; Pest è un framework che vi si basa, con una sintassi più breve. Attualmente PHPUnit è alla versione 13 (da febbraio 2026, da PHP 8.4), Pest è alla versione 5. I test automatici non chiudono le vulnerabilità in PHP stesso, ma rendono pianificabili gli aggiornamenti: dopo PHP2Shell e prima della fine del supporto di PHP 8.2 il 31/12/2026 è il vantaggio decisivo.

Perché testare il codice PHP?

Per la direzione l'utilità si riassume in una frase: i test rendono le modifiche più economiche e più sicure. Un test automatico verifica in pochi secondi se una funzione fa ancora ciò che deve, ad esempio se un carrello calcola correttamente o se un login rifiuta le password errate. Senza test lo verifica una persona a mano, oppure nessuno.

La differenza è particolarmente evidente con gli aggiornamenti. Quando PHP deve essere aggiornato in tempi brevi per una vulnerabilità critica, molti gestori esitano perché temono errori nello shop o nel portale clienti. Con una suite di test l'aggiornamento gira prima in un ambiente di test, i test mostrano i problemi e poi si va online.

PHPUnit: lo standard per i test PHP

PHPUnit esce ogni anno a febbraio con una nuova versione principale. Ogni versione richiede una versione minima di PHP e riceve circa due anni di correzioni di errori. Secondo phpunit.de vale:

La tabella mostra un nesso pratico: un progetto che usa ancora PHPUnit 10 di solito gira anche su una vecchia versione di PHP. Strumenti di test e versione di PHP dovrebbero essere aggiornati insieme. PHPUnit si installa di norma tramite Composer come dipendenza di sviluppo.

Un primo test con PHPUnit

Un test è una classe che estende PHPUnit\Framework\TestCase. I metodi di test sono pubblici e iniziano con test, in alternativa si contrassegnano con l'attributo #[Test]. L'esempio verifica una semplice funzione per il calcolo del prezzo:

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

Il data provider fornisce più casi per lo stesso test. Secondo la documentazione di PHPUnit deve essere pubblico e statico. Si calcola in centesimi come intero, perché non si verifichino errori di arrotondamento dovuti ai numeri in virgola mobile. La suite viene eseguita con ./vendor/bin/phpunit, se PHPUnit è installato tramite Composer.

Pest: la stessa base, sintassi più breve

Secondo la documentazione Pest è costruito su PHPUnit. I test si scrivono come funzioni con it() o test() e le aspettative con expect(). Pest 5 richiede PHP 8.4. L'installazione secondo la documentazione:

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

Lo stesso test nella sintassi di Pest:

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

I test PHPUnit esistenti vengono convertiti in gran parte automaticamente dal plugin pestphp/pest-plugin-drift. Quale sintassi scelga un team è questione di gusto; decisivo è che i test girino con regolarità.

Quali tipi di test sono sensati

1. Unit test: verificano singole funzioni e classi senza database né rete.
2. Test di integrazione: verificano l'interazione con database, file system o interfacce.
3. Test funzionali via HTTP: richiamano pagine e moduli come farebbe un browser.
4. Test di regressione della sicurezza: fissano gli errori corretti, ad esempio che gli output vengano neutralizzati con htmlspecialchars() o che un login fallisca dopo una password errata.
5. Smoke test dopo il deployment: pochi controlli rapidi per vedere se il sito live risponde dopo un aggiornamento.

A complemento dei test, l'analisi statica con PHPStan e Psalm trova errori senza eseguire il codice.

I test come rete di sicurezza per aggiornamenti e PHP2Shell

PHP2Shell ha mostrato quanto possa essere breve il tempo tra la pubblicazione e la pressione ad agire: annuncio il 20/10/2026, patch il 21/10/2026, livello di allerta arancione del BSI (Ufficio federale tedesco per la sicurezza delle informazioni). Chi aveva una suite di test poteva installare PHP 8.4.27 o 8.3.36 in un ambiente di test, far girare i test e andare online lo stesso giorno. Senza test restava spesso solo la scelta tra un aggiornamento non verificato e una vulnerabilità aperta.

Il vantaggio è ancora maggiore nel cambio di versione principale. Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali, e PHP 8.2 termina il 31/12/2026, come spiega la pagina Fine del ciclo di vita di PHP. Un'esecuzione dei test sulla versione di destinazione mostra presto quali funzioni obsolete vadano sostituite. È sensata una pipeline CI che esegua i test su più versioni di PHP, oltre a uno sguardo alle release candidate come PHP 8.6.0, ma mai in produzione.

Come aiuta concretamente PHP SOS?

Nella migrazione da PHP 8.1 e precedenti e negli aggiornamenti in corso offriamo questo supporto:

• Valutare l'esistente: quali test esistono, quali versioni di PHP e PHPUnit girano, dove mancano test per i processi critici?
• Creare una copertura minima: insieme al Suo team di sviluppo o alla Sua agenzia mettiamo in sicurezza con test login, moduli e percorsi di ordine.
• Testare gli aggiornamenti: le nuove versioni di PHP girano prima in un ambiente di test rispetto alla suite.
• Documentare il risultato: riceve risultati dei test e stati delle versioni come prova del passaggio di patch o di migrazione.

Domande frequenti

Fonti

• PHPUnit
• Pest
• php.net: versioni di PHP supportate