Ciao, e benvenuto nella quinta puntata della sessantanovesima stagione. Fin qui ho parlato dei test come di una cosa buona, e lo sono. Ma sarei disonesto se ti lasciassi credere che scrivere test sia sempre, automaticamente, un guadagno. Ci sono test che non solo non aiutano: ti fanno attivamente male, perché ti regalano una sicurezza che non hai. Oggi è la puntata scomoda. Parliamo dei test che ti ingannano, e del perché una suite tutta verde a volte è peggio di nessuna suite.
Partiamo dal caso più subdolo: il test che non prova niente ma sembra provare qualcosa. È il test tautologico, quello che, senza accorgertene, verifica solo se stesso. Ricordi le controfigure della scorsa puntata? Se prepari una controfigura che risponde quattro, e poi verifichi che il risultato sia quattro, cosa hai testato? Hai testato che quattro è uguale a quattro. Il tuo codice vero, in mezzo, non ha fatto niente di interessante. Il test è verde, sembra serio, e non ti protegge da assolutamente nulla. Sono i più insidiosi, perché occupano lo spazio di un test vero senza farne il lavoro. E capitano facilmente proprio a chi abusa delle controfigure: finisci per provare la scena che hai preparato tu, non il codice.
Vediamo il secondo tranello, quello che ti logora nel tempo: il test troppo attaccato ai dettagli. Un buon test verifica cosa fa il codice, il suo comportamento. Un test scritto male verifica come lo fa, i suoi passaggi interni. La differenza sembra sottile, ma le conseguenze sono enormi. Se leghi il test ai dettagli interni, ogni volta che riscrivi quel codice per migliorarlo, senza cambiarne il comportamento, il test si rompe lo stesso. E allora smetti di migliorare il codice, per non dover riscrivere i test. Il test, che doveva darti libertà, è diventato una gabbia. Ti sei costruito una suite che urla a ogni riordino, ma resta muta davanti ai bug veri.
E ora il peggiore di tutti, quello che avvelena i team: il test ballerino. Quello che a volte passa e a volte no, senza che tu abbia toccato niente. Lanci la suite, è rossa. La rilanci, è verde. Che fai? All'inizio indaghi. Poi, siccome capita spesso, cominci a rilanciare finché non diventa verde. E qui è successo il disastro: hai insegnato al team a ignorare i test rossi. Perché quando un test ballerino urla al lupo dieci volte per niente, l'undicesima, quando il lupo c'è davvero, non gli crede più nessuno. Un solo test inaffidabile può rovinare la fiducia in tutta la suite. Meglio cancellarlo, o ripararlo subito, che lasciarlo lampeggiare a caso. Un test deve fallire per una ragione, sempre la stessa, oppure non fallire affatto.
Nota adesso il grande idolo falso del testing, quello di cui tutti parlano e che tutti fraintendono: la copertura. La copertura misura quante righe del tuo codice vengono eseguite dai test. E la gente insegue quel numero: ottanta per cento, novanta, cento. Ma pensa bene a cosa dice davvero quel numero. Dice quali righe sono state toccate, eseguite. Non dice che il loro comportamento è stato verificato. Posso scrivere un test che esegue tutto il tuo codice, ogni singola riga, e non controlla neanche un risultato. Copertura cento per cento, valore zero. La copertura ti dice dove i test non sono mai arrivati, e in quello è utile. Ma un numero alto non significa codice sicuro: significa solo codice attraversato.
C'è un filo comune sotto tutti questi casi, ed è il vero pericolo della puntata. Tutti questi test cattivi hanno un tratto in comune: sono verdi. Danno l'apparenza della sicurezza senza la sostanza. E questo è peggio di non avere test, perché un progetto senza test lo sai che è scoperto, e stai attento. Un progetto con una suite verde ma vuota ti fa sentire protetto mentre cammini sul vuoto. La falsa sicurezza è più pericolosa dell'insicurezza dichiarata, perché ti toglie la prudenza proprio dove ne avresti più bisogno.
Ecco la lezione che voglio lasciarti, e vale ben oltre il testing. Un esperimento mal disegnato non ti dà mezza conoscenza: ti dà una conclusione sbagliata con l'aria di essere giusta. Un test cattivo non è metà di un test buono: è una trappola travestita da rete di sicurezza. La domanda da farsi non è mai ho abbastanza test, o ho abbastanza copertura. La domanda giusta è: se un bug entrasse qui, adesso, uno dei miei test diventerebbe rosso? Se la risposta è no, quel test, per quanto verde, non ti sta proteggendo. Ti sta solo facendo compagnia.
Per oggi ci fermiamo qui. Abbiamo guardato il lato scomodo: i test che ingannano. Il test tautologico, che verifica solo se stesso e la sua controfigura. Il test troppo attaccato ai dettagli interni, che si rompe a ogni miglioramento e ti imprigiona invece di liberarti. Il test ballerino, il peggiore, che insegna al team a ignorare il rosso e avvelena la fiducia in tutta la suite. E l'idolo della copertura, che misura le righe toccate, non i comportamenti verificati: cento per cento e valore zero convivono benissimo. Il filo comune è che sono tutti verdi, e la falsa sicurezza è peggio dell'insicurezza dichiarata. Nella prossima puntata: scrivere i test prima. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.