Ciao, e benvenuto nella nona puntata della sessantanovesima stagione. Arriviamo alla domanda che divide i programmatori più di quasi ogni altra, la domanda scomoda che nessuna delle puntate precedenti ha voluto affrontare di petto: quanto bisogna testare? Quanti test sono abbastanza? È qui che le persone litigano, si dividono in fazioni, e sventolano numeri come bandiere. Oggi non ti do una risposta secca, ma qualcosa di più utile: un modo per trovare la tua, caso per caso.
Partiamo dai due modi di sbagliare, perché stanno ai due estremi opposti. Da una parte c'è il testare troppo poco. Nessuna rete di sicurezza, paura a ogni modifica, bug che arrivano dritti agli utenti, e quel senso costante di camminare sul ghiaccio sottile. Lo abbiamo raccontato. Ma dall'altra parte, e questo si dice molto meno, c'è il testare troppo. Una suite gonfia, che costa più da mantenere del codice che protegge, che rallenta ogni modifica perché venti test si rompono per un cambiamento innocuo, piena di test su cose banali che non si romperanno mai. Anche questo è uno spreco, e a volte peggiore, perché ti convince di essere prudente mentre stai solo rallentando.
Vediamo le due fazioni che si scontrano, perché tu le incontrerai di sicuro. Da un lato i puristi della copertura: cento per cento o niente, ogni riga deve avere il suo test, chi non lo fa è un irresponsabile. Dall'altro i pragmatici sbrigativi: i test sono una perdita di tempo, spediamo e sistemiamo in produzione, il vero test sono gli utenti. Come quasi sempre in questo podcast, la verità comoda non sta con nessuna delle due tifoserie. Hanno torto tutti e due, perché fanno la stessa cosa: danno una risposta unica e fissa a una domanda che dipende dal contesto.
E qui c'è la sintesi, la regola che scioglie il nodo. Non testi tutto allo stesso modo. Concentri i test dove ci sono due cose insieme: il rischio e il cambiamento. Rischio: quanto fa male se questo pezzo si rompe? Il calcolo di un pagamento che sbaglia è un disastro; un colore sbagliato in un angolo della pagina, no. Cambiamento: quanto spesso metti le mani su questo pezzo? Il codice che tocchi ogni settimana ha bisogno della rete; quello scritto tre anni fa e mai più toccato, molto meno: se funziona e nessuno lo sfiora, un test in più lì rende poco. Dove rischio e cambiamento sono alti, testa a fondo. Dove sono bassi, testa poco o niente, senza sensi di colpa.
Nota una conseguenza che libera parecchio: contesti diversi chiedono quantità diverse. Il codice che pilota un dispositivo medico, o che muove i soldi di una banca, va testato in un modo che a uno script buttato giù per sistemare dei file una volta sola sembrerebbe follia. E viceversa: pretendere lo stesso rigore su un prototipo, fatto per essere buttato via la settimana dopo, è tempo sprecato due volte. La domanda giusta non è quanto si testa in generale. È quanto va testato questo, qui, adesso, dato cosa rischio e quanto cambia. È una domanda che si fa a ogni pezzo, non una volta per tutte.
C'è un modo di pensarci che uso sempre, ed è la stessa idea che torna in questo podcast stagione dopo stagione. Non esiste lo strumento migliore in assoluto: esiste quello giusto per il lavoro che hai davanti. Il testing è uguale. Non esiste la quantità giusta di test in assoluto, esiste la dose giusta per questo pezzo, in questo momento, con questi rischi. Chi cerca la regola universale, valida sempre e ovunque, sta cercando qualcosa che non esiste, e finirà per essere troppo rigido dove serve leggerezza, e troppo leggero dove serve rigore.
Voglio lasciarti con l'immagine che rende tutto intuitivo: il testing è un'assicurazione. Quanta assicurazione compri? Non ne compri nessuna, e non ti assicuri fino all'ultimo centesimo per ogni minima cosa. Ti assicuri in proporzione a quanto rischi di perdere. Sulla casa, tanta. Su un ombrello da pochi euro, nessuna: se lo perdi, ne ricompri un altro. I test sono esattamente questo: un premio che paghi oggi, in tempo, per non pagare un danno molto più grande domani. E come per ogni assicurazione, la domanda non è averla o non averla. È: quanta, su cosa, dato cosa mi costerebbe il guasto. Il testing, in fondo, non è un rito da compiere: è gestione del rischio.
Per oggi ci fermiamo qui. Abbiamo affrontato la domanda che divide: quanto testare. Ci sono due modi di sbagliare, testare troppo poco e testare troppo, e due fazioni che sbagliano allo stesso modo, dando una risposta fissa a una domanda che dipende dal contesto. La sintesi è concentrare i test dove rischio e cambiamento sono alti, e alleggerire dove sono bassi, senza sensi di colpa. Contesti diversi chiedono dosi diverse: il dispositivo medico non è lo script usa e getta. Non esiste la quantità giusta in assoluto, esiste la dose giusta qui e ora, come non esiste lo strumento migliore ma quello adatto. Il testing è un'assicurazione: gestione del rischio, non un rito. Nella prossima e ultima puntata: il dubbio sistematico. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.