Risposta.

I test automatici sono suddivisi in unitari (unit), di integrazione (integration) e end-to-end (end-to-end, E2E), per coprire in modo completo il controllo del sistema a diversi livelli.

Storia della questione: Questa classificazione è nata dalla necessità di testare le applicazioni sia a livello di singole parti che nel loro insieme. Pertanto, vengono distinti i livelli di test:

funzione specifica (unit)
interazione tra le parti (integration)
sistema intero, funzionante per l'utente (E2E)

Problema: Gli errori si verificano spesso non solo nella logica di un singolo metodo, ma anche nei punti di contatto tra i componenti, o durante l'esecuzione "reale" dell'intero sistema con servizi esterni. Se si mescolano tutto in un unico insieme, è difficile localizzare rapidamente un bug o capire dove sia effettivamente sorto.

Soluzione:

I test unitari controllano codice isolato, di solito a livello di funzioni o classi semplici. Nei casi avanzati vengono utilizzati mock e stub.
I test di integrazione collegano tra loro più componenti (ad esempio, un modulo e un DB) per vedere come funzionano insieme.
I test end-to-end (E2E) simulano scenari utente — l'intero percorso "dal pulsante al risultato".

Distinguere i tipi di test è vitale per:

Minimizzare i costi di manutenzione (i test E2E sono costosi)
Mantenere un feedback rapido (i test unitari sono istantanei)
Ridurre il numero di falsi positivi

Caratteristiche chiave:

Una corretta distribuzione dei test aiuta a costruire un approccio "a piramide" affidabile (piramide dei test).
La mescolanza degli stili di test porta a problemi di localizzazione dei bug.
Una chiara comprensione dello scopo di ciascun livello porta alla massima efficienza.

Domande trabocchetto.

Si possono considerare i test di integrazione semplicemente "grandi" test unitari?

No, i test di integrazione testano il funzionamento di più componenti insieme, e non solo singole funzioni. Inoltre, non sempre è possibile utilizzare mock: i servizi reali interagiscono tra loro.

Devono tutti i test essere end-to-end (E2E)?

No, questo è un approccio costoso e complesso. Gli E2E sono necessari solo per scenari utente critici; la maggior parte della logica è coperta da altri test.

I test unitari sono sempre veloci?

Non sempre. A volte, non è possibile isolare il codice, o il metodo dipende da risorse esterne complesse. In tal caso, il test smette di essere unitario.

Errori tipici e anti-pattern

Tutti i test sono scritti solo come E2E, il feedback diventa estremamente lento.
Confusione nei livelli: il test unitario inizia ad accedere al DB o all'API, mentre gli E2E sono basati su mock.
Vengono lasciati solo i test unitari: bug problematici nei punti di contatto tra componenti non vengono identificati.

Esempio dalla vita reale

Caso negativo

In un'azienda, la funzionalità principale è stata coperta solo con test E2E — ogni modifica veniva controllata di notte, i test fallivano in modo instabile e i bug venivano scoperti tardi.

Pro:

Scenari reali degli utenti sono coperti.

Contro:

Feedback lento.
Lunghe analisi delle cause dei guasti.
Molti falsi positivi.

Caso positivo

Il team ha costruito una piramide di test: basso — test unitari, medio — test di integrazione, alto — solo gli E2E più importanti.