Ciao, e benvenuto nella terza puntata della sessantanovesima stagione. Sappiamo com'è fatto un singolo test: prepara, agisci, verifica. Ma nel mondo reale non scrivi un test, ne scrivi centinaia, e non sono tutti uguali. Ce ne sono di minuscoli e velocissimi, e di enormi e lentissimi. Oggi mettiamo ordine in questa varietà, con un'immagine classica del nostro mestiere: la piramide dei test. È un modo semplice per capire quali test scrivere, e soprattutto quanti.
Partiamo dai tre piani della piramide, dal basso verso l'alto. In fondo, alla base larga, ci sono i test di unità. Prendono un pezzo piccolo di codice, una funzione, una classe, e lo mettono alla prova da solo, isolato da tutto il resto. Sono l'esperimento in provetta: condizioni pulite, una variabile, risposta immediata. Nel mezzo ci sono i test di integrazione. Qui non provi un pezzo da solo, ma verifichi che due o più pezzi collaborino bene: il codice e il database, il servizio e la coda dei messaggi. In cima, alla punta stretta, ci sono i test end-to-end. Questi provano il sistema intero, dall'inizio alla fine, come lo userebbe una persona vera: apri la pagina, compili il modulo, premi invio, e controlli cosa succede davvero.
Vediamo perché la forma è proprio una piramide, larga sotto e stretta sopra, perché è tutto lì il messaggio. Man mano che sali, ogni test diventa più realistico: prova qualcosa di più vicino a ciò che vive l'utente. Ma nello stesso tempo diventa più lento, più fragile, e più difficile da capire quando fallisce. Un test di unità gira in un millesimo di secondo e, se si rompe, sai subito dove guardare. Un test end-to-end può metterci minuti, dipende dalla rete, dal browser, dai tempi, e quando diventa rosso a volte non sai nemmeno se la colpa è del tuo codice o dell'ambiente. Realismo e fragilità crescono insieme. Ecco perché ne vuoi tanti in basso, dove costano poco e parlano chiaro, e pochi in alto, dove costano molto e sono capricciosi.
E qui c'è un compromesso che devi imparare a leggere, perché è il vero cuore della piramide. Da una parte c'è l'isolamento: più isoli un pezzo, più il test è veloce e preciso, ma più ti allontani da come il sistema funziona davvero, tutto insieme. Dall'altra c'è il realismo: più provi il sistema intero, più la tua fiducia è giustificata, ma più paghi in lentezza e fragilità. Non esiste il test perfetto che ha tutto: veloce, preciso, realistico e stabile. Ogni piano della piramide sceglie un punto diverso su questo scambio. La piramide non ti dice di scegliere un tipo solo: ti dice di mescolarli nella giusta proporzione.
Nota l'errore classico, quello in cui cadono tantissimi team, perché ha persino un nome buffo. Si chiama il cono gelato: la piramide rovesciata. Sono i progetti dove ci sono pochissimi test di unità e una montagna di test end-to-end. All'inizio sembra sensato: proviamo tutto come lo vede l'utente, no? Ma il risultato è una suite lentissima, che ci mette mezz'ora a girare, piena di test che falliscono a caso per motivi che non c'entrano col codice. Il team smette di fidarsene, e a quel punto tanto vale non averli. Il cono gelato è comodo da leccare all'inizio, ma si scioglie e ti sporca le mani.
C'è un altro modo di dire la stessa cosa, che tiene tutto insieme. Ogni tipo di test risponde a una domanda diversa. Il test di unità chiede: questo pezzo, da solo, si comporta come deve? Il test di integrazione chiede: questi pezzi, messi insieme, si parlano correttamente? Il test end-to-end chiede: dal punto di vista di chi lo usa, il sistema fa quello che promette? Sono domande tutte legittime, ma con costi molto diversi. La saggezza sta nel rispondere a più domande che puoi con i test economici, in basso, e riservare i test costosi, in alto, alle poche cose che solo loro possono davvero verificare.
Ripensa per un attimo alla stagione scorsa. Avevamo distinto i piccoli passi dai grandi passi: guardare l'esecuzione al rallentatore, o guardare solo il risultato finale. La piramide è lo stesso spirito applicato al testing. In basso guardi da vicino, un passo per volta, un pezzetto isolato. In alto guardi da lontano, il risultato complessivo, tutta la partita insieme. Ti servono entrambe le distanze: quella ravvicinata per capire i dettagli, quella panoramica per fidarti dell'insieme. Nessuna delle due, da sola, ti dà il quadro completo.
Per oggi ci fermiamo qui. Abbiamo messo ordine nei tanti test con la piramide: alla base larga i test di unità, veloci e isolati, l'esperimento in provetta; nel mezzo l'integrazione, dove i pezzi collaborano; in cima, pochi, gli end-to-end, che provano il sistema come lo vive l'utente. La forma dice tutto: salendo cresce il realismo, ma crescono anche lentezza e fragilità. Il compromesso è tra isolamento e realismo, e nessun test le ha tutte. Da qui l'errore del cono gelato, la piramide rovesciata, con troppi test lenti e capricciosi di cui il team smette di fidarsi. Ogni piano risponde a una domanda diversa: usa i test economici per rispondere a quante più domande puoi. Nella prossima puntata: isolare il pezzo. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.