Codice testato

Per fare codice di qualità ci affidiamo all’utilizzo dei test che, nel nostro caso, significano Unit test, Integration test, TDD e BDD. Come sviluppatori siamo perfettamente consapevoli che il codice testato porta benefici a tutti: il cliente avrà ciò che vuole, ovvero un prodotto funzionante e verificabile.

Non testiamo tutto a prescindere; il testing è una pratica che aumenta i tempi di sviluppo e di conseguenza i costi. Nella fase iniziale di analisi del progetto, insisme al cliente, cerchiamo di rispondere a queste due domande: "Quanto può cambiare l’applicazione nei prossimi mesi?" "Quali sono i punti in cui non è accettabile un bug?". La risposta a queste domane ci indica quali sono le porzioni di codice in cui implementare test.

• Permette di sapere in anticipo quale parte del codice è stata compromessa durante un nuovo sviluppo potento intervenire prima della pubblicazione.
• I flussi e le interazioni vengono verificate in pochi minuti e non in ore di testing umano che è sempre fallibile per banali disattenzioni.
• È una vera e propria documentazione del codice, senza il bisogno di scrivere documentazione prolissa e verbosa.
• Permette una manutanzione nel tempo: bastano poche settimane per "perdere il filo del discorso" e avere dei test ci permette di ricostruire il percorso fatto.
• Permette a nuovi sviluppatori di entrare a progetto inziato, senza avere paura di "spaccare tutto".
• Permette ad un cliente di cambiare team in blocco, senza correre il rischio di dover "rscrivere tutto".

Unit test

Lo scopo dello Unit Testing è quello di verificare il corretto funzionamento di singole classi o metodi di classe. Non dovrebbe mai varcare i confini della classe, lavorando in completo isolamento e restituendo al programmatore una prova certa che un pezzo di codice funzioni correttamente.

Integration test

Gli Integration Test ci consentono di individuare i problemi che si verificano quando due unità si combinano per realizzare una funzionalità più complessa. Fondamentalmente si verificano le interfacce in entrata e in uscita di ciascuno oggetto, assicurandoci che gli oggetti sappiano parlare tra loro.

Test Driven Development

Il TDD è una delle pratiche suggerite dall’XP (Extreme Programming), così come il pair programming ecc. Il suo mantra — red, green refactor — rappresenta un ciclo iterativo in cui: decidi cosa vuoi ottenere, scrivi un test, lo vedi fallire, scrivi il codice per farlo passare, fai il refactoring e poi da capo.

In generale, il valore dei test si concretizza in una maggiore confidenza nel refactoring, e dunque una maggiore mantenibilità del codice; il TDD aumenta questo valore perché ci costringe a pensare prima alle interfacce e solo dopo all’implementazione, permettendoci così di ottenere un’architettura migliore.

Behaviour Driven Development

Il BDD è un’estensione del TDD che nasce (fuori dal contesto agile dell’XP) per rispondere alla domanda: bello il TDD, ma cosa devo effettivamente testare? La risposta si trova nella parola chiave "comportamento", inteso come comportamento verificabile anche dal cliente. Di fatto, tecnicamente, il BDD non è molto diverso dal TDD; è più un approccio filosofico che permette agli sviluppatori e al management di comunicare tra loro, con un lessico condiviso che vada verso ciò che ha davvero valore per il business del cliente. Si parte da ciò che il cliente vede e che è descritto nelle user stories che, di fatto, sono il primo test più esterno di una certa funzionalità.