Home Blogs C’è di più nello sviluppo basato sui test che nel QA
Applications

C’è di più nello sviluppo basato sui test che nel QA

About The Author

Outline

Molti, se non la maggior parte, nel mondo del software sono giunti a pensare allo sviluppo basato su test (TDD, test-Driven Development ) solo come a un processo specifico per lo sviluppo del software. Molte discussioni e dibattiti si sono incentrate sull’uso di strumenti o tecniche specifici progettati per esercitare ogni angolo di codice rispetto a un elenco predefinito di requisiti allo scopo di dimostrare che un dato codebase funziona come descritto. Come accade troppo spesso, diventa difficile separare il segnale dal rumore e il principio dalla pratica, quindi ci perdiamo nei dettagli di attuazione e perdiamo di vista l’intento originale. Pertanto, facciamo un passo indietro e miriamo a riconsiderare la conversazione relativa allo sviluppo basato sui test: Nello specifico, che cos’è e in che modo può aiutare la tua azienda?

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 il software per soddisfare questi requisiti e, man mano che il progetto e il suo codice aumentano, come si può garantire che il software continui a soddisfare questi requisiti

Accedere a test-driven Development.

Test-Driven Development, o TDD, è una metodologia organizzativa per scrivere software scrivendo test che descrivono ed esercitano tale software. Al suo interno, TDD è una ripetizione di tre passaggi: Scrivere un test non riuscito, farlo passare, refattore.

Il concetto è che si inizia con un test che descrive una parte di funzionalità per qualsiasi funzione software in fase di sviluppo. L’esecuzione di questo test per la prima volta dovrebbe produrre un errore, perché il codice in fase di test non è ancora stato scritto. Naturalmente, il passo successivo consiste nell’implementazione della funzione, con l’obiettivo di superare il test originale. Il terzo passo, e probabilmente il più importante, del ciclo di vita, è il refattore del codice.

Scrivere software è difficile non solo per le sue qualità intrinseche, ma anche per la sua natura dinamica. I requisiti aziendali possono variare costantemente e, di conseguenza, i requisiti software devono essere in grado di adattarsi. Il codice che è scritto oggi si adatta alle esigenze di oggi, ma domani, o 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 è esecuzione di una registrazione di ciò che il software dovrebbe stiamo facendo ora abbiamo un potente strumento che ci permetterà di strappare, riscrivere e altrimenti ricablare il nostro codice per soddisfare al meglio i requisiti odierni, perché possiamo essere sicuri che finché tutti i nostri test passano, l’output del sistema dovrebbe essere lo stesso.

Perché dovremmo usare 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 avvenire a scapito di maggiori sforzi di sviluppo. Questa non è una conclusione sorprendente, dato che la scrittura di test aggiuntivi richiederà ulteriori sforzi – ma ciò che studi di questa natura sembrano escludere è il vantaggio chiave del TDD, che è il feedback.

Chiudere il ciclo di feedback significa abbreviare il tempo necessario per apportare una modifica e apprendere qualcosa. Più rapidamente si può fare questo, più agile si può essere. La maggior parte delle metriche che tentano di quantificare la produttività dello sviluppo si riferiscono alle unità di lavoro nel tempo e, riducendo il tempo necessario per ricevere feedback attuabili, il TDD consente un uso più efficiente di quella preziosa risorsa. È stato detto che il tempo è denaro, quindi il beneficio economico qui è evidente. Se hai mai sentito qualcuno menzionare un “spostamento di 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 l’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 dei test di fumo o di una pipeline ci/CD. Automatizzando i passaggi per la distribuzione del codice sul mercato, consente una consegna più rapida del prodotto nel suo insieme, 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 codebase che consente agli sviluppatori di adattare continuamente il codebase alle esigenze aziendali e la possibilità per l’azienda di richiedere rapidamente il feedback dei clienti, il risultato è un sistema che consente ai team di offrire più valore con meno lavoro.

Ottenere il massimo da TDD

Lo sviluppo basato sui test è solo uno dei tanti approcci diversi per testare il software. La parte importante, indipendentemente dalla scelta di implementarla, è che offre valore alla vostra organizzazione. Come qualsiasi altra disciplina, dovreste sentirvi liberi di usarla, adattarla come ritenete opportuno o non utilizzarla affatto, in base alle esigenze della vostra organizzazione. Detto questo, se scegli di percorrere il sentiero del 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 i difetti di un progetto, ma è un povero artigiano che incolpa i suoi strumenti. Quindi concentriamoci su come ottenere il massimo da TDD.

Rifactoring culturale

L’ultimo passo, e più importante, del TDD è quello di refattorizzare il codice, ma per il TDD non è probabilmente l’unico refactoring che deve accadere. Se si sceglie di implementare una qualche forma di test-driven Development, è importante che la cultura circostante si adatti anche a sostenere questo stile di filosofia di sviluppo.

Nel caso del TDD, il fallimento più comune tende ad essere che il ciclo continuo di test di scrittura, che li fa passare, e poi il refactoring non è mai effettivamente completato, ma piuttosto è cortocircuitato saltando il passaggio di refactoring. Più spesso 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 sono stretti perché dopo tutto, qualcuno deve scrivere tutti questi test. E quindi ne consegue che durante i tempi di lancio i test e la documentazione, e qualsiasi altra cosa che non è considerata mission critical vengono eliminati. Ciò che segue invariabilmente è un calo costante della qualità complessiva della base di codici e al suo posto un accumulo di debito tecnico.

Il refactoring è la fase del processo che cerca di 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. Potrebbe 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 ultima analisi, la base di codice rischia una trasformazione graduale (o meno) in una grande palla di fango.

Per raccogliere i vantaggi dello sviluppo basato su test, è 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 i bit che sono espedienti.

Shiny New Toys

Quando si tratta di progettare un sistema nel suo complesso, spesso viene impiegato troppo tempo per pianificare le specifiche di un sistema senza scrivere alcun codice. Un progetto “green Field” può essere eccitante, con tutto il potenziale di previsione associato a un foglio di carta pulito. Ingegneri e architetti cadono vittime di questa malattia, in cui sostengono l’uso di una tecnologia “sapore del mese”, ignorando qualsiasi segnale di avvertimento che potrebbe non essere adatto per questo particolare progetto a favore dell’opportunità di provare qualcosa di nuovo o di fresco. Andiamo avanti di pochi mesi e il framework-du-jour non soddisfa più le esigenze del team, la qualità del codice sta soffrendo, e siamo tornati alla parte in cui la tecnologia diventa il capro espiatorio per il cattivo esito del progetto.

Alla fine della giornata, ciò che è importante è che la tecnologia, la metodologia o il framework utilizzati per facilitare TDD funzioni per il team e per l’azienda. Se sei ostacolato dai tuoi strumenti, non solo non stanno aggiungendo valore, ma stanno attivamente lavorando contro di te. Fai attenzione a valutare accuratamente qualsiasi framework che intendi utilizzare e prenditi il tempo per capire esattamente come lo userai. Questo approccio vale per tutte le decisioni di progettazione, non solo per quelle relative al TDD!

Conclusione

In poche parole, l’idea di qualcosa come TDD è quella di fornire un framework per raccogliere feedback in modo più rapido e non semplicemente una tecnica per impedire che i bug vengano visualizzati nel codebase. Qualunque sia l’approccio scelto, la chiave deve essere quella di consentire alla vostra azienda e al suo software di adattarsi più rapidamente alle tendenze e alle esigenze aziendali in evoluzione. Lungo la strada, ricordati che TDD e le sue controparti non sono semplicemente qualcosa che puoi chiedere al tuo team di sviluppo di implementare e poi dimenticare, e per sfruttare efficacemente queste tecniche occorre prestare attenzione ad adottare e consentire l’approccio a livello culturale prima di immergersi nei dettagli dell’implementazione, come framework e strumenti.