# Testare il codice PHP: PHPUnit e Pest

> PHPUnit e Pest spiegati: versioni, primi test, tipi di test sensati e perché i test rendono gli aggiornamenti dopo PHP2Shell più sicuri e più rapidi.

Fonte: https://phpsos.de/it/php/php-testen/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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:

| PHPUnit | Uscita | Requisito PHP | Correzioni di errori fino al |
|---|---|---|---|
| 13 | 06/02/2026 | da PHP 8.4 | 04/02/2028 |
| 12 | 07/02/2025 | da PHP 8.3 | 05/02/2027 |
| 11 | 02/02/2024 | da PHP 8.2 | 06/02/2026 |
| 10 | 03/02/2023 | da PHP 8.1 | 07/02/2025 |

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](https://phpsos.de/it/php/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
<?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:

```bash
composer remove phpunit/phpunit
composer require pestphp/pest --dev --with-all-dependencies
./vendor/bin/pest --init
```

Lo stesso test nella sintassi di Pest:

```php
<?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](https://phpsos.de/it/php/statische-analyse/) 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](https://phpsos.de/it/ratgeber/php-end-of-life-risiken/). 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.

> **Consiglio:**
> Scriva un test per ogni errore di sicurezza corretto nella Sua applicazione. Così si assicura che lo stesso errore non ritorni con una modifica successiva.

## Come aiuta concretamente PHP SOS?

Nella [migrazione da PHP 8.1 e precedenti](https://phpsos.de/it/leistungen/php-migration-legacy/) 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

**Quale versione di PHPUnit mi serve?**  
Dipende dalla Sua versione di PHP. PHPUnit 13 richiede PHP 8.4, PHPUnit 12 PHP 8.3 e PHPUnit 11 PHP 8.2. La tabella aggiornata si trova su phpunit.de, tra le versioni supportate.

**Pest sostituisce PHPUnit?**  
Secondo la propria documentazione Pest è costruito su PHPUnit e offre una sintassi più breve. I test PHPUnit esistenti si possono in gran parte convertire automaticamente con il plugin Drift, alcuni vanno adattati a mano.

**I test aiutano contro le vulnerabilità in PHP stesso?**  
Non direttamente. Vulnerabilità come PHP2Shell si trovano nell'interprete e si chiudono con un aggiornamento di PHP. I test fanno però in modo che possa installare tale aggiornamento rapidamente, senza timore di errori inosservati nell'applicazione.

**Quanti test bastano?**  
Non esiste un numero fisso. È sensato coprire prima i percorsi critici per l'attività: accesso, ordine, moduli, interfacce. Poi la copertura dei test cresce a ogni modifica e a ogni errore corretto.

## Fonti

- [PHPUnit](https://phpunit.de/)
- [Pest](https://pestphp.com/)
- [php.net: versioni di PHP supportate](https://www.php.net/supported-versions.php)
