Test automatizzati: perché il codice non testato è debito

Quasi tutti i team concordano, in teoria, sull’importanza dei test automatizzati. E quasi ogni squadra, in pratica, trova una scusa per lasciarli da parte. "Non abbiamo tempo adesso." "Il progetto è semplice." "Testiamo manualmente." Sono frasi che precedono, con impressionante regolarità, il momento in cui tutto comincia a rompersi.

Il test automatizzato è uno di quegli argomenti in cui la distanza tra discorso e pratica è enorme. E questa distanza ha un costo, pagato non tutto in una volta, ma a rate crescenti nel corso della vita del prodotto.

Questo testo spiega perché i test non sono più facoltativi e cosa cambia veramente quando un team li prende sul serio. Non è un tutorial. È un argomento, l'argomento di qualcuno che ha visto, da entrambe le parti, cosa succede con e senza test.

Cosa sono realmente i test automatizzati

I test automatizzati sono programmi che controllano automaticamente se il tuo software fa quello che dovrebbe fare. Invece di una persona che fa clic e controlla manualmente ogni modifica, una suite di test esegue questo controllo in pochi secondi, tutte le volte necessarie.

Ma ridurre il testing alla “verifica che funzioni” non coglie il punto. I test automatizzati sono, innanzitutto, una rete di sicurezza. Catturano informazioni su come dovrebbe comportarsi il sistema e avvisano quando un cambiamento interrompe tale comportamento.

Questa rete cambia completamente la relazione del team con il codice stesso. Senza di essa, ogni cambiamento è una scommessa. Con esso ogni cambiamento è un’ipotesi verificabile.

Perché questo è diventato non negoziabile

Il software cresce e cambia continuamente. Vengono aggiunte funzionalità, i bug vengono risolti, il codice viene riorganizzato. Ciascuno di questi cambiamenti comporta il rischio di rompere qualcosa che precedentemente funzionava.

In un piccolo sistema, puoi testare tutto manualmente. In un sistema reale, che cresce di mese in mese, questo diventa impossibile. Nessuno può fare clic su tutti i flussi con ogni modifica. Il risultato del provarci è stanchezza, lentezza e insetti che comunque sfuggono.

I test automatizzati sono la risposta a questo problema di scala. Consentono al software di crescere senza che la verifica diventi un collo di bottiglia per l'uomo. Ecco perché hanno smesso di essere affinamenti di team maturi e sono diventati una condizione fondamentale per costruire qualcosa che duri.

La tesi: i test riguardano il coraggio, non i bug

Ecco la mia posizione e potrebbe sorprenderti. Il valore più grande dei test automatizzati è non trovare bug. È dare coraggio a cambiare il codice.

Pensa alla squadra senza test. Ogni cambiamento in una parte sensibile del sistema è accompagnato dalla paura. "Questo romperà qualcos'altro?" Questa paura paralizza. Porta il team a evitare miglioramenti, a lasciare il codice difettoso così com'è, a non cambiare ciò che funziona per pura paura. Il prodotto marcisce per giustificata codardia.

Ora pensiamo alla squadra con buone prove. Lo stesso cambiamento è accompagnato dalla fiducia. Se qualcosa si rompe, i test te lo fanno sapere subito. Il team può rifattorizzare, migliorare, evolversi senza paura. Questa libertà è il vero dono della prova. Non solo proteggono ciò che esiste, ma lasciano liberi il team di costruire ciò che verrà dopo.

I tipi di test e quando utilizzarli

Non tutti i test sono uguali e comprendere le differenze previene inutili sforzi.

I test unitari controllano porzioni di codice piccole e isolate. Sono veloci, economici e dovrebbero essere la base. Rilevano errori specifici e forniscono un feedback quasi istantaneo.

I test di integrazione verificano se le diverse parti funzionano bene insieme. Sono più lenti, ma colgono i problemi che quelli dell'unità non vedono, le colpe che vivono nelle giunzioni.

I test end-to-end simulano l'utilizzo nel mondo reale, dall'inizio alla fine. Sono i più lenti e fragili, ma i più vicini all'esperienza dell'utente. Vanno usati con parsimonia, nei flussi più critici.

La saggezza sta nell'equilibrio: molti test veloci nella parte inferiore, pochi test lenti nella parte superiore. Invertire questa proporzione è un classico errore che genera suite lente e instabili che il team impara a ignorare.

Un esempio applicabile

Immagina un sistema che calcoli i benefici sociali per un programma pubblico. Le regole sono complesse e cambiano a seconda della legislazione. Un errore di calcolo potrebbe significare che un cittadino riceve un importo sbagliato, in più o in meno.

Senza test, ogni modifica alle regole rappresenta un rischio enorme. Nessuno è sicuro che cambiare una regola non ne abbia infranta un'altra. La squadra è tenuta in ostaggio dalla paura e gli errori finiscono per raggiungere il cittadino.

Grazie ai test automatizzati che coprono le regole di calcolo, ogni modifica viene verificata rispetto a decine di scenari noti in pochi secondi. Se una modifica risolve un caso, il team lo sa prima di pubblicarlo. L'affidabilità non dipende più dalla memoria di qualcuno ed è ormai garantita dal sistema. In qualcosa che tocca la vita delle persone, questa differenza non è tecnica, è etica.

Le trappole che invalidano lo sforzo

La prima trappola è testare in base al numero, non al valore. Le squadre che inseguono una percentuale di copertura come obiettivo finiscono per scrivere test inutili per gonfiare la metrica. Un’elevata copertura di test errati è una falsa sicurezza.

La seconda è la suite lenta e instabile. Quando i test durano troppo a lungo o falliscono in modo casuale, il team perde fiducia in loro e inizia a ignorarli. Un test saltato non tutela nessuno. La manutenzione della suite stessa è un lavoro in corso.

Il terzo è considerare il testing come un compito separato, da svolgere successivamente. I test funzionano meglio quando fanno parte dello sviluppo, non quando diventano un passaggio aggiuntivo che viene sempre lasciato fino alla fine e non avviene mai.

Il codice senza test è un debito che accumula interessi

Alla fine, la scelta non è tra testare o non testare. La questione è tra pagare adesso o pagare più tardi, con gli interessi. Il codice non testato è un debito tecnico che cresce silenziosamente fino a incassare la fattura nel peggior momento possibile.

I team che investono nei test non sono più lenti, sono più coraggiosi. Si muovono con la sicurezza di chi ha una rete di sicurezza sotto. E questa fiducia, moltiplicata per mesi e anni di sviluppo, è ciò che distingue i prodotti che si evolvono da quelli che arrugginiscono.

Testare non significa diffidare del tuo codice. Si tratta di rispettare il futuro di coloro che lo manterranno, compreso te stesso.

Se il tuo team fornisce software temendo di cambiare ciò che già esiste, forse il problema non è la mancanza di talento, ma la mancanza di rete. Vale la pena parlarne. Ho altri articoli di blog sulla qualità del software, sulle migliori pratiche e sulla progettazione che approfondiscono come costruire tale fiducia.