Questo tema è la prima volta che lo affronto qui, anche se su Linkedin in questo post lo avevo già trattato, ma per me non è mai abbastanza e quindi
Perchè lo promuovi così tanto?
Questa è la domanda che molte volte mi sento chiedere (parafrasata) da tutti quelli che cerco di spingere a fare test su tutti gli aspetti che si vuole implementare.
E la risposta è semplice: Tranquillità
Tranquillità nel sapere che quello che hai scritto funziona come ti aspetti.
Tranquillità nel fare modifiche senza dover fare mille controlli.
Tranquillità nel sapere che una cosa la devi ancora implementare.
Perchè vuoi tutta questa tranquillità?
Quando ero alle superiori, ci era stato affidato di fare un gioco in JavaScript e scelsi 2048.
Il gioco in se non è difficile, ma all’epoca scrivevo codice molto poco leggibile ( e l’ho tratato nel altro post: La scrittura e il codice: binomio ).
E qui che passavo le ore a provare tutte le combinazioni, fino alla nausea, per ogni singola modifica che facevo.
Fino ad arrivare al punto in cui credevo che funzionava e non toccavo più il codice per evitare altri test manuali.
Quando poi ho compreso questo concetto mi sono detto:
“Quante ore avrei risparmiato di fatica su queste attività?
E quanto sarei stato molto più concentrato sul codice in se che sull’essere sicuro di aver fatto tutti i controlli?”
I sistemi controllano gli input, perché non anche il codice?
Noi creiamo programmi per gestire la logica, controllando che l’utente inserisca i dati corretti e cercando di bloccare tutto quello che non è stato definito.
In questo le macchine sono migliori di noi e quindi, se gli lasciamo fare anche il controllo del nostro codice, lo riescono a fare in tempi molto più brevi di noi e anche molto meglio, senza tralasciare nessun aspetto che gli diciamo.
E quindi, ogni volta che spendiamo del tempo nel codificare i casi limite che vogliamo testare, sarà tutto tempo risparmiato quando dobbiamo implementare, lanciando i test e capendo se il codice supera quello che gli abbiamo imposto e, soprattutto, che stia funzionando anche quello che non ci aspettiamo di aver modificato.
E un altro vantaggio è…
Documentare lo stato del sistema
Perché i test a tutti gli effetti è una documentazione di quello che il nostro sistema fa e non fa.
Rispetto a una documentazione scritta, che può diventare obsoleta rispetto all’evoluzione del sistema, possiamo eseguirla sempre e capire se c’è qualcosa che non torna.
A volte una nuova implementazione può far cambiare la logica, quindi dobbiamo poi cambiare anche i test e questo ce li fa tenere aggiornati.
Altre volte invece, quando ci sono delle evolutive, iniziando dai test (TDD style), ci permette di capire meglio dove vogliamo arrivare e anche quali passi dobbiamo fare per farlo.
In più, per sistemi grandi o comunque che vengono dati ad altre persone, la possibilità di avere i test che coprono tutto quello che si è implementato da il beneficio di capire se, un idea che il cliente vuole attuare, non va a scontrarsi con qualcosa di già esistente.
Conclusione
Anche se un concetto semplice, per me è molto importante, perchè permette di lavorare con una rete di sicurezza da farmi far si che possa andare veloce e nello stesso tempo di proteggermi in caso di sbagli.