Glossario · Fondamenti del testing
Test di integrazione
In inglese: Integration test
Detto anche: integration testing, test d'integrazione
Definizione
Un test che verifica se due o più componenti, come un servizio e il suo database o due API, funzionano correttamente insieme attraverso le loro interfacce reali.
Un test di integrazione verifica le connessioni tra i componenti, invece della logica all’interno di uno solo. Usa implementazioni reali su almeno un confine: un repository contro un database reale, un servizio che chiama l’API di un altro servizio, un producer di messaggi e il suo consumer. Sono i test che intercettano SQL errato, serializzazione sbagliata, configurazione mancante e contratti non allineati, tutte cose che i test unitari con i mock non vedrebbero.
Esempio
Un OrderRepository è coperto da test unitari con mock, e quei test passano. Il test di integrazione lo esegue contro un’istanza reale di PostgreSQL avviata in un container:
- Avvia PostgreSQL con Testcontainers e applica le migrazioni dello schema.
- Salva tramite il repository un ordine con tre righe.
- Ricaricalo per ID e verifica che totali e righe corrispondano.
- Interroga gli ordini per intervallo di date e verifica che gli estremi siano inclusi.
Eseguito contro un database reale, questo test può rivelare un refuso nel nome di una colonna, una migrazione mai applicata, un errore di conversione del fuso orario o una query che funziona in un database in memoria ma non in PostgreSQL.
Test di integrazione, unitari ed end-to-end a confronto
| Unitario | Integrazione | End-to-end | |
|---|---|---|---|
| Ambito | Una funzione o una classe | Alcuni componenti e le loro interfacce | L’intero sistema, come un utente |
| Dipendenze | Sostituite da test double | Reali sul confine sotto test | Tutte reali |
| Velocità | Millisecondi | Secondi | Da secondi a minuti |
| Un fallimento indica | Un punto preciso della logica | Un’interfaccia precisa | Un punto qualsiasi del sistema |
Approcci
- I test di integrazione ristretti verificano un confine alla volta (servizio più database) con tutto il resto simulato tramite stub. Sono veloci e precisi, e la maggior parte dei team ne vuole molti.
- I test di integrazione ampi avviano insieme più servizi reali. Danno più fiducia ma sono più lenti e più difficili da diagnosticare.
- I manuali classici descrivono anche l’integrazione big-bang, top-down e bottom-up, che indicano l’ordine in cui i moduli vengono combinati. Nei colloqui è utile conoscere questi termini, ma i team moderni integrano per lo più in modo continuo.
Errori comuni
- Condividere un unico database di lunga durata tra test e sviluppatori, il che rende i risultati dipendenti dai dati residui. Dai a ogni esecuzione un’istanza pulita e usa e getta.
- Simulare con un mock proprio il confine che volevi testare, trasformando un test di integrazione di nuovo in un test unitario.