TDD e il mito del 100% code coverage

Abstract

Un’applicazione con il 100% di code coverage che non funziona? Sulla carta è perfetta, ma in produzione fallisce.

In questo intervento lampo da 25 minuti tra talk e live-coding, partiamo da un paradosso tipico dello sviluppo software: una suite di test unitari impeccabili e ricchi di mock e spy che garantisce una copertura quasi totale delle righe di codice, ma lascia le reali funzionalità scoperte e piene di bug. Attraverso una rapida sessione di refactoring dal vivo sul repository, mostriamo come superare l’illusione delle metriche e riscoprire il valore del TDD all’interno dell’eXtreme Programming.

Le pratiche adottate da eXtreme Programming sono svariate e nessuna può essere presa da sola e applicata in modo efficace: ognuna si combina con le altre per creare qualcosa di più grande. Il TDD è uno degli abilitatori principali: permette di soddisfare il cliente rilasciando software di valore, consegnare frequentemente software funzionante, far emergere requisiti e architetture, esaltare semplicità ed eccellenza tecnica.

PS: ma la code coverage? Serve per la nostra vanità — e forse per soddisfare l’ego di qualcuno.

Cosa hanno imparato i partecipanti

Oltre le metriche di vanità: come trasformare la stesura dei test da adempimento formale a vero motore dell’eccellenza tecnica.

I partecipanti a questa sessione hanno potuto toccare con mano:

• L’illusione della copertura teorica: perché una percentuale di Code Coverage elevata (o persino del 100%) rappresenta spesso solo una metrica di vanità che non assicura il corretto funzionamento dell’applicazione nel suo insieme.
• I rischi dei test accoppiati all’implementazione: come l’uso abusivo di mock e spy porti a test solitari strettamente legati ai dettagli di codice anziché ai reali comportamenti del sistema, creando una falsa sensazione di sicurezza.
• La sinergia delle pratiche XP e i Customer Test: l’importanza di integrare il TDD all’interno dell’eXtreme Programming, affiancando ai test unitari i Customer Test (test automatici delle funzionalità) per validare il software con il cliente, rilasciare frequentemente valore reale e perseguire la semplicità.
• I primi passi verso una strategia su più livelli: come far emergere nel codice la necessità di una strategia di testing guidata dai comportamenti (Behavior-Driven) e strutturata su diversi livelli di astrazione, ponendo le basi per superare la fragilità dei soli test unitari isolati.