Che cos’è TDD?
Nel contesto di un’azienda, lo scopo del software è quello di aggiungere valore a tale azienda. Per questo motivo, una delle sfide principali di qualsiasi sforzo di sviluppo è la mappatura dei requisiti e degli obiettivi aziendali nei corrispondenti requisiti di sistema. A questo punto, la domanda diventa: Come si scrive un software per soddisfare questi requisiti e, man mano che il progetto e la base di codice crescono, come si fa a garantire che il software continui a soddisfare questi requisitiPartecipate a test-Driven Development.
Test-Driven Development, o TDD, è una metodologia organizzativa per scrivere software scrivendo test che descrivono ed esercitano tale software. Il TDD è una ripetizione di tre fasi: Scrivere un test fallito, farlo passare, refattorizzare.
L’idea è che si inizi con un test che descrive una funzionalità per qualsiasi funzione software in fase di sviluppo. Eseguire quel test per la prima volta dovrebbe produrre un errore, perché il codice che viene testato non è ancora stato scritto. Naturalmente, il passo successivo consiste nell’implementare la funzione, con l’obiettivo di far superare il test originale. Il terzo, e probabilmente il più importante passo del ciclo di vita, consiste nel riconsiderare il codice.
Il software di scrittura è difficile non solo per le sue qualità intrinseche, ma anche per la sua natura dinamica. I requisiti aziendali possono cambiare costantemente e, di conseguenza, i requisiti software devono essere in grado di adattarsi. Il codice scritto oggi si adatta alle esigenze di oggi, ma domani, o a un mese da domani, qualcosa cambierà, e di conseguenza, il codice di oggi potrebbe non essere più il modo migliore per risolvere un particolare problema. Introducendo un meccanismo per confrontare i software è fare per registrare il software dovrebbe stiamo facendo ora abbiamo uno strumento potente che ci permetterà di strappare senza paura, riscrivere e altrimenti ricablare il nostro codice per soddisfare al meglio i requisiti di oggi, perché possiamo essere sicuri che, finché tutti i nostri test supereranno, l’output del sistema dovrebbe essere lo stesso.
Perché dovremmo usare il TDD?
Una revisione del 2014 condotta dall’Università di Helsinki ha rilevato che in molti casi il TDD ha prodotto effetti positivi in termini di difetti, qualità, complessità e manutenibilità, ma che questi miglioramenti possono andare a discapito di un maggiore impegno di sviluppo. Questa non è una conclusione sorprendente, dato che la scrittura di ulteriori test richiederà ulteriori sforzi – ma quali studi di questa natura sembrano tralasciare è il vantaggio principale di TDD, che è il feedback.
Chiudere il ciclo di feedback significa ridurre il tempo necessario per apportare un cambiamento e imparare qualcosa. Più velocemente si può fare, più agile si può essere. La maggior parte delle metriche che tentano di quantificare la produttività di sviluppo si riferisce alle unità di lavoro nel tempo e, riducendo il tempo necessario per ricevere feedback attuabili, TDD consente un utilizzo più efficiente di questa preziosa risorsa. È stato detto che il tempo è denaro, quindi il vantaggio economico qui è ovvio. Se hai mai sentito qualcuno menzionare un “spostamento a sinistra” nel contesto del ciclo di vita dello sviluppo del software, questo è esattamente ciò a cui si riferiscono.
Un ulteriore vantaggio di avere una suite di test per la vostra applicazione è la possibilità di automatizzarla. Non solo gli sviluppatori possono eseguire questi test come parte del ciclo di vita dello sviluppo, ma possono essere eseguiti da altri sistemi come parte del test di fumo o di una pipeline ci/CD . Automatizzando le fasi di consegna del codice sul mercato, consente una consegna più rapida del prodotto nel suo complesso, il che a sua volta accelera il feedback che gli utenti possono ricevere, che può quindi essere interpretato e applicato all’iterazione successiva.
Gli effetti sinergici di questi due punti sono chiari: Con un codice base che consente agli sviluppatori di adattare continuamente il codice base alle esigenze dell’azienda e la possibilità per l’azienda di sollecitare rapidamente il feedback dei clienti, il risultato è un sistema che consente ai team di offrire più valore con meno lavoro.
Ottenere il massimo dal TDD
Il test-Driven Development non è che uno dei tanti approcci diversi al testing del software. La parte importante, indipendentemente dalla vostra scelta di implementarla, è che offre valore alla vostra organizzazione. Come qualsiasi altra disciplina, dovreste sentirvi liberi di usarla, adattarla a vostro piacimento o non utilizzarla affatto, in base alle esigenze della vostra organizzazione. Detto questo, se scegli di percorrere il percorso TDD, come predisse il profeta Clapton: “È nel modo in cui lo usi”.
Come qualsiasi altro strumento, l’efficacia e il valore del TDD dipendono dalla sua implementazione. Troppo spesso nello sviluppo di software vari strumenti o tecniche vengono trasformati in capro espiatorio per spiegare i fallimenti o le carenze di un progetto, ma è un povero artigiano che incolpa i suoi strumenti. Quindi concentriamoci su come ottenere il massimo da TDD.
Refactoring culturale
L’ultimo, e più importante passo del TDD è quello di refattorizzare il codice – ma per il funzionamento del TDD questo probabilmente non è l’unico refactoring che deve accadere. Se si sceglie di implementare una qualche forma di test-Driven Development, è importante che anche la cultura circostante si adatti a sostenere questo stile di filosofia di sviluppo.
Nel caso del TDD, il guasto più comune tende ad essere che il ciclo continuo di prove di scrittura, facendole passare, e poi il refactoring non è mai effettivamente completato, ma piuttosto è cortocircuitato saltando la fase di refactoring. Più spesso che non il problema non è TDD, o qualsiasi altra tecnica specifica, ma piuttosto la stessa cultura in cui il software è sviluppato.
Non a differenza della documentazione, il refactoring sembra essere una delle prime cose gettate in mare quando le scadenze o i budget si restringono perché, dopo tutto, qualcuno deve scrivere tutti questi test. Ne consegue che durante i momenti di crisi i test e la documentazione, e qualsiasi altra cosa che non sia considerata mission critical, vengono eliminati. Ciò che segue invariabilmente è un costante calo della qualità complessiva della base di codici e al suo posto un accumulo di debito tecnico.
Il refactoring è la fase del processo che si impegna a trasformare il codice che funziona semplicemente in un codebase più pulito e gestibile. È la parte che consente agli sviluppatori di fare un passo indietro e riconoscere i modelli all’interno del sistema generale e di prendere decisioni più informate su come potrebbero essere adattati per essere più versatili o per riconoscere gli anti-pattern emergenti e adottare misure per mitigarli. Può anche essere la differenza tra riconoscere quando è il momento di dividere l’architettura complessiva in microservizi discreti o qualsiasi altro di una miriade di potenziali miglioramenti. Senza questo passaggio, si possono perdere opportunità di introspezione e miglioramento incrementale e, in definitiva, il codice base rischia una graduale (o meno) trasformazione in una grande sfera di fango.
Per cogliere i vantaggi del test-Driven Development, è importante che la cultura prenda una visione lunga del processo nel suo complesso e del suo potenziale, e investa il tempo nell’applicazione del ciclo completo “rosso, verde, refattore”, e non solo dei bit che sono opportuni.
Giocattoli nuovi e splendenti
Quando si tratta di progettare un sistema nel suo complesso, spesso si impiega troppo tempo a pianificare le specifiche di un sistema senza scrivere alcun codice. Un progetto “green Field” può essere entusiasmante, con tutto il potenziale previsionale associato a un foglio di carta pulita. Ingegneri e architetti sono vittime di TRY-This-ITIS, in cui sostengono l’uso di una tecnologia “Flavor of the month”, ignorando qualsiasi segnale di avvertimento che potrebbe non essere adatto a questo particolare progetto a favore dell’opportunità di provare qualcosa di nuovo o fresco. Avanti di pochi mesi e il framework-du-jour non soddisfa più le esigenze del team, la qualità del codice ne risente, e siamo tornati alla parte in cui la tecnologia diventa il capro espiatorio per il cattivo risultato del progetto.
Alla fine della giornata ciò che conta è che la tecnologia, la metodologia o il framework utilizzati per facilitare il TDD funzionino per il team e per l’azienda. Se sei ostacolato dai tuoi strumenti, non solo non stanno aggiungendo valore, ma stanno lavorando attivamente contro di te. Fai attenzione a valutare a fondo qualunque struttura intendi utilizzare e prenditi il tempo di capire esattamente come lo userai. Questo approccio vale per tutte le decisioni di progettazione, non solo per quelle relative al TDD!
Conclusione
In breve, l’idea di qualcosa come TDD è fornire un framework per raccogliere feedback in modo più opportuno e non semplicemente una tecnica per impedire che i bug vengano visualizzati nel codice base. Qualunque sia l’approccio scelto, la chiave dovrebbe essere che consenta alla vostra azienda e al suo software di adattarsi più rapidamente alle tendenze e alle esigenze aziendali in continua evoluzione. Lungo il percorso, tieni presente che TDD e le sue controparti non sono semplicemente qualcosa che puoi chiedere al tuo team di sviluppo di implementare e poi dimenticare, e che per sfruttare efficacemente queste tecniche è necessario prestare attenzione ad abbracciare e abilitare l’approccio a livello culturale prima di immergerti nei dettagli dell’implementazione come framework e strumenti.
