Test driven development
Il test-driven development (abbreviato in TDD), in italiano sviluppo guidato dai test[1] o sviluppo guidato dalle verifiche[2] è un modello di sviluppo del software basato su test automatici. Il modello prevede che lo sviluppo avvenga attraverso la ripetizione di un breve ciclo in tre fasi. Nella prima fase (detta "fase rossa"), il programmatore scrive un test automatico per la nuova funzione da sviluppare, che deve fallire in quanto la funzione non è stata ancora realizzata. Nella seconda fase (detta "fase verde"), il programmatore sviluppa la quantità minima di codice necessaria per passare il test. Nella terza fase (detta "fase grigia" o di refactoring), il programmatore esegue il refactoring del codice per adeguarlo a determinati standard di qualità.[3] L'invenzione del metodo (o la sua riscoperta[4]) si deve a Kent Beck, uno dei padri dell'extreme programming (XP) e dello metodologie agili. Il TDD è una delle 12 regole base dell'XP ma viene anche usato indipendentemente da questa metodologia;[5] la sua applicazione è anche parte fondamentale dello sviluppo agile del software.[6]
Descrizione
Il processo si articola sulla ripetizione di brevi cicli di sviluppo e collaudo (noti come "cicli TDD", TDD cycles) suddivisi in tre fasi successive, sintetizzate dal motto "Red-Green-Refactor".
- nella prima ("Red"), il programmatore scrive un test automatico (che necessariamente fallisce) per la funzionalità da sviluppare.
- nella seconda ("Green"), il programmatore scrive la quantità minima di codice necessaria per ottenere il superamento del test.
- nella terza, il programmatore ristruttura il codice (ovvero ne fa il refactoring).
I colori "rosso" e "verde" si riferiscono alla rappresentazione grafica di fallimento e successo di un test automatico più diffusa negli IDE.
Vantaggi
Tali test permettono di individuare con precisione le specifiche del codice, e quindi il suo comportamento in base alle situazioni a cui sarà sottoposto. Ciò facilita la produzione di un codice funzionante in qualunque circostanza, più pulito e più affidabile.
Scrivendo i test prima del codice, si utilizza il programma prima ancora che venga realizzato. Ci si assicura, inoltre, che il codice prodotto è testabile singolarmente. È dunque obbligatorio avere una visione precisa del modo in cui verrà utilizzato il programma prima ancora d'essere implementato. Così facendo si evitano errori concettuali durante la realizzazione dell'implementazione, senza che si siano definiti gli obiettivi. Inoltre, i test consentono agli sviluppatori di avere maggior confidenza durante il refactoring del codice, in quanto già sanno che i test funzioneranno quando richiesto; pertanto, possono permettersi di effettuare cambiamenti radicali di design, stando certi che alla fine otterranno un programma che si comporterà sempre alla stessa maniera (essendo i test sempre verificati).
L'uso del Test Driven Development permette non solo di costruire il programma assieme ad una serie di test di regressione automatizzabili, ma anche di stimare in maniera più precisa lo stato d'avanzamento dello sviluppo di un progetto.
Voci correlate
Collegamenti esterni
- ^ [C. Lairman e L. Cabibbo, Applicare UML e i pattern: analisi e progettazione orientata agli oggetti, Prentice-Hall 2005, p. 400
- ^ [http://www2.mokabyte.it/cms/article.run?articleId=UQM-B5J-1V4-588_7f000001_10364476_fc0fddeb C. Bottiglieri, Test-driven development: un esempio con una web app, Mokabyte n. 192, febbraio 2014
- ^ K. Beck, Test--Driven Development by Example, Addison Wesley 2003
- ^ Why does Kent Beck refer to the "rediscovery" of test-driven development?
- ^ [Newkirk, JW and Vorontsov, AA. Test-Driven Development in Microsoft .NET, Microsoft Press 2004]
- ^ TDD, Agile Alliance