Vai al contenuto

Pest in Laravel: scrivere test che verificano un comportamento

Pest è un framework di test PHP che può essere integrato in Laravel. Offre una sintassi compatta, ma il valore di una verifica dipende dal comportamento controllato: un test breve può essere preciso oppure confermare soltanto ciò che il setup ha appena creato.

Controllare la configurazione del progetto

Verifica PHP, PHPUnit e versione di Pest compatibili seguendo la guida ufficiale di installazione. In un progetto già avviato, controlla composer.json e tests/Pest.php prima di aggiungere dipendenze o inizializzare nuovamente la suite.

I test Feature devono usare il TestCase Laravel per avere accesso all’applicazione e agli helper HTTP. Questo collegamento è diverso da un test unitario PHP che esegue soltanto una funzione.

Un esempio HTTP autonomo

Il seguente test definisce una rotta solo durante la prova, quindi verifica risposta e contenuto. Presuppone l’integrazione Laravel configurata per tests/Feature.

use Illuminate\Support\Facades\Route;

it('restituisce lo stato previsto', function () {
    Route::get('/test-status', fn () => ['status' => 'ready']);

    $this->getJson('/test-status')
        ->assertOk()
        ->assertExactJson(['status' => 'ready']);
});

È una dimostrazione della sintassi, non un test utile del tuo prodotto. Nel progetto reale interroga una rotta esistente e verifica un requisito che potrebbe rompersi. La guida alla scrittura dei test Pest spiega la struttura delle funzioni it e test.

Scegliere cosa deve fallire

Per un endpoint riservato, proverei accesso consentito, utente senza permessi e risorsa appartenente a un altro cliente. Per una creazione, controllerei dati salvati e comportamento con input non valido.

Verificare che una factory produca un nome non nullo, da solo, dice poco sulla funzione dell’applicazione che interessa all’utente.

Conoscere il confine del test

Un test HTTP Laravel non esegue automaticamente JavaScript nel browser. Una simulazione del servizio email non prova il recapito del provider. Questi confini determinano quali problemi la suite può rilevare.

Usa un database di test separato quando servono dati e una preparazione ripetibile. L’obiettivo è poter introdurre un errore nel comportamento e vedere la verifica fallire per la ragione corretta.