Test Driven Development (TDD): Ridurre i costi e migliorare la documentazione dello sviluppo software
Introduzione al TDD
Nel mondo odierno dove c’è più concorrenza fra le aziende di sviluppo del software, i clienti optano per una scelta che fornisca software di qualità e affidabile. Il test del software è forse la miglior strategia per perseverare questi due obiettivi. Così per avere un buon software a bassi costi, dovrebbe essere necessario scrivere il test a priori, per individuare gli errori e poi passare all’implementazione. Il migliore approccio per fare ciò è TDD (Test Driven Development). L’obiettivo del TDD è proprio quello di far diminuire il costo dei test ed aumentare la qualità del software finale, usando appunto la tecnica di testing TDD.
Ridurre i costi e migliorare la documentazione tramite TDD
Si utilizza questo approccio, poiché è noto da tempo che i costi maggiori relativi al rilascio del software incidevano proprio sul testare l’applicazione alla fine del processo di sviluppo. In TDD il cliente, espone il requisito che il software deve avere, un test case viene scritto al fine di raggiungere questo ed infine si passa allo sviluppo, che non termina fino al superamento del test. Quando un requisito è soddisfatto si passa alla fase di refactoring, che mira a migliorare il design e la qualità, scrivendo un altro test per garantire che il requisito sia rispettato. Il fascino di questo metodo è quello di non avere un disegno ben definito dall’inizio, infatti si sviluppa come noi vogliamo che sia il software.
Come già detto questo modello è utile per abbattere i costi di produzione del software, anche se in alcuni casi il costo complessivo è equiparabile a quello del normale ciclo di sviluppo del software.
Il modello TDD basic è illustrato nella figura seguente.
Modello TDD avanzato
L’idea è apportare alcune modifiche all’approccio TDD, cioè quando lo sviluppatore non riesce a risolvere un problema dopo un certo numero di tentativi, invece di continuare a testare l’applicazione, potrebbe scomporre il requisito in più sub-requisiti, il test in più sub-test, in modo tale da poter ricercare gli errori in uno spazio ridotto rispetto al precedente. Qualora neanche in questo caso fosse possibile rintracciare l’errore, si procederà in maniera analoga a quanto descritto. ” il test di unità potrebbe essere perfino ridotto ad un metodo o ad una procedura”. Se apportiamo queste modifiche, lo schema del TDD modificato è visibile nella seguente figura.
