Test driven development: differenze tra le versioni

Versione delle 21:19, 21 ott 2011

Versione attuale delle 10:07, 6 ott 2024

(61 versioni intermedie di 30 utenti non mostrate)

Riga 1:

In [[informatica]], nello [[sviluppo software]], il '''test-driven development''' (abbreviato in '''TDD'''), in italiano '''sviluppo guidato dai test'''<ref>[[Craig Larman|C. Larman]] e L. Cabibbo, ''Applicare UML e i pattern: analisi e progettazione orientata agli oggetti'', Prentice-Hall 2005, p. 400</ref> o '''sviluppo guidato dalle verifiche'''<ref>[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] {{webarchive|url=https://web.archive.org/web/20141222150628/http://www2.mokabyte.it/cms/article.run?articleId=UQM-B5J-1V4-588_7f000001_10364476_fc0fddeb |data=22 dicembre 2014 }}</ref> è un [[modello di sviluppo del software]] che prevede che la stesura dei [[Automazione del collaudo del software|test automatici]] avvenga ''prima'' di quella del [[software]] che deve essere sottoposto a test, e che lo sviluppo del [[applicazione (informatica)|software applicativo]] sia orientato ''esclusivamente'' all'obiettivo di passare i test automatici precedentemente predisposti.

{{S|informatica}}

Il '''Test Driven Development''' (TDD) è un [[ciclo di vita del software|processo di sviluppo del software]] in cui si creano i test prima del [[codice sorgente]] di un [[software]]. Obiettivo primario di questo processo è quindi la specificazione e non la validazione del codice.

Più in dettaglio, il TDD prevede la ripetizione di un breve ciclo di sviluppo in tre fasi, detto "ciclo TDD". 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 sorgente|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à.<ref>[[Kent Beck|K. Beck]], ''Test-Driven Development by Example'', Addison Wesley 2003</ref>

Sviluppato e diffuso da [[Kent Beck]], fa parte delle 12 regole alla base dell'[[Extreme Programming]] (XP). Si tenga conto che mentre XP è una metodologia agile, il Test Driven Development è una pratica agile.

L'invenzione del metodo (o la sua riscoperta<ref>[https://www.quora.com/Why-does-Kent-Beck-refer-to-the-rediscovery-of-test-driven-development ''Why does Kent Beck refer to the "rediscovery" of test-driven development?'']</ref>) si deve a [[Kent Beck]], uno dei padri dell'[[extreme programming]] (XP) e delle [[metodologie agili]]. Il TDD è una delle 12 regole base dell'XP, ma viene anche usato indipendentemente da questa metodologia;<ref>Newkirk, JW and Vorontsov, AA. ''Test-Driven Development in Microsoft .NET'', Microsoft Press 2004</ref> la sua applicazione è anche parte fondamentale dello sviluppo agile del software.<ref>{{Cita web |url=http://guide.agilealliance.org/guide/tdd.html |titolo=''TDD'', Agile Alliance |accesso=22 dicembre 2014 |dataarchivio=8 febbraio 2015 |urlarchivio=https://web.archive.org/web/20150208110313/http://guide.agilealliance.org/guide/tdd.html |urlmorto=sì }}</ref>

==Ciclo di sviluppo==

Il Test Driven Development si articola in 5 fasi:

# scrittura del test;

# verifica del fallimento del test (poiché non esiste ancora il codice che deve testare);

# scrittura del codice per superare il test;

# verifica del superamento del test;

# [[refactoring]] del codice.

==Vantaggi I cicli TDD ==

[[File:Test-driven development.PNG|upright=1.6|thumb|Rappresentazione tramite [[diagramma di flusso]] del ciclo TDD]]

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.

Il TDD si articola in brevi cicli che constano di tre fasi principali. La descrizione originale dei cicli TDD data da [[Kent Beck]] nel libro ''Test-Driven Development by Example''<ref name=Beck>K. Beck, ''Test-Driven Development by Example'', Addison Wesley 2003</ref> è quella usata universalmente come riferimento:

=== Fase rossa ===

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).

Nel TDD, lo sviluppo di una nuova funzionalità comincia sempre con la stesura di un test automatico volto a validare quella funzionalità, ovvero verificare se il software la esibisce. Poiché l'implementazione non esiste ancora, la stesura del test è un'attività creativa, in quanto il programmatore deve stabilire in quale forma la funzionalità verrà esibita dal software e comprenderne e definirne i dettagli. Perché il test sia completo, deve essere eseguibile e, quando viene eseguito, produrre un esito negativo. In molti contesti, questo implica che debba essere realizzato una bozza minimale del codice da testare, necessario per garantire la compilazione e l'esecuzione del test. Una volta che il nuovo test è completo e può essere eseguito, dovrebbe fallire. La fase rossa si conclude quando c'è un nuovo test che può essere eseguito e fallisce.

=== Fase verde ===

Nella fase successiva, il programmatore deve scrivere la quantità minima di codice necessaria per passare il test che fallisce. Non è richiesto che il codice scritto sia di buona qualità, elegante, o generale; l'unico obiettivo esplicito è che funzioni, ovvero passi il test. In effetti, è esplicitamente vietato dalla pratica del TDD lo sviluppo di parti di codice non strettamente finalizzate al superamento del test. Quando il codice è pronto, il programmatore esegue nuovamente tutti i test disponibili sul software modificato (non solo quello che precedentemente falliva). In questo modo, il programmatore ha modo di rendersi conto immediatamente se la nuova implementazione ha causato fallimenti di test preesistenti, ovvero ha causato regressioni o peggioramenti nel codice. La fase verde termina quando tutti i test vengono passati con successo.

=== Refactoring o fase grigia===

{{Vedi anche|refactoring}}

Quando il software passa tutti i test, il programmatore dedica una certa quantità di tempo a farne ''refactoring'', ovvero a migliorarne la struttura attraverso un procedimento basato su piccole modifiche controllate volte a eliminare o ridurre difetti oggettivamente riconoscibili nella struttura interna del codice. Esempi tipici di azioni di refactoring includono la scelta di identificatori più espressivi, eliminazione di codice duplicato, semplificazione e razionalizzazione dell'architettura del sorgente (p.es. in termini della sua organizzazione in classi), e così via. La letteratura sul TDD fornisce numerose linee guida sia specifiche che generali sul modo corretto di fare refactoring<ref>K. Beck, ''XP Explained'', Addison-Wesley 1999</ref><ref>Robert C. Martin, ''Clean Code''</ref> In ogni caso, l'obiettivo del refactoring non è quello di ottenere del codice "perfetto", ma solo di ''migliorarne'' la struttura, secondo la cosiddetta "regola dei Boy Scout"<ref>Garry Shutler, ''The Boy Scout Rule''</ref>: "lascia l'area dove ti sei accampato più pulita di come l'hai trovata". Dopo ciascuna azione di refactoring, i test automatici vengono nuovamente eseguiti per accertarsi che le modifiche eseguite non abbiano introdotto errori.

==Ciclo Stile di sviluppo ==

{{citazione|Write new code only if an automated test has failed|Kent Beck, ''Test-Driven Development by Example''}}

{{citazione|Only ever write code to fix a failing test|Lasse Koskela, ''Test Driven''}}

{{citazione|We produce well-designed, well-tested, and well-factored code in small, verifiable steps|James Shore, ''Agile Development''}}

Il principio fondamentale del TDD è che lo sviluppo vero e proprio deve avvenire ''solo'' allo scopo di passare un test automatico che fallisce. In particolare, questo vincolo è inteso a impedire che il programmatore sviluppi funzionalità non esplicitamente richieste, e che il programmatore introduca complessità eccessiva in un progetto, per esempio perché prevede la necessità di generalizzare l'implementazione in un futuro più o meno prossimo. In questo senso il TDD è in stretta relazione con numerosi principi della programmazione agile e dell'[[extreme programming]], come il principio [[KISS (principio)|KISS (Keep It Simple, Stupid)]], il principio YAGNI ([[You aren't gonna need it]]), e il mandato agile di minimizzare il lavoro incompiuto.<ref name="Shore">James Shore, ''Agile Development''</ref>

I cicli TDD sono intesi come cicli di breve durata, al termine di ciascuno dei quali il programmatore ha realizzato un piccolo incremento di prodotto (con i relativi test automatici), un altro concetto tipico delle metodologie agili.<ref name="Shore"/> L'applicazione reiterata del refactoring al termine di ogni ciclo ha lo scopo di creare codice di alta qualità e buone architetture in modo incrementale, tenendo però separati l'obiettivo di costruire software funzionante (fase verde) e quello di scrivere "buon codice" (fase grigia). La breve durata dei cicli TDD tende anche a favorire lo sviluppo di componenti di piccole dimensioni e ridotta complessità.

== Vantaggi ==

L'applicazione del TDD porta in generale allo sviluppo di un numero maggiore di test, e a una maggiore copertura di test del software prodotto, rispetto alla pratica tradizionale di sviluppare i test dopo l'implementazione.<ref>{{Cita web |url=http://nparc.cisti-icist.nrc-cnrc.gc.ca/npsi/ctrl?action=shwart&index=an&req=5763742&lang=en |titolo=H. Erdogmus, ''On the Effectiveness of Test-first Approach to Programming'' |accesso=22 dicembre 2014 |urlarchivio=https://web.archive.org/web/20141222180731/http://nparc.cisti-icist.nrc-cnrc.gc.ca/npsi/ctrl?action=shwart&index=an&req=5763742&lang=en |dataarchivio=22 dicembre 2014 |urlmorto=sì }}</ref> In parte, questo è dovuto al fatto che in contesti non TDD il management tende a spingere i programmatori a passare all'implementazione di nuove funzionalità a scapito del completamento dei test. I programmatori che usano il TDD su progetti nuovi hanno, in genere, meno necessità di usare il [[debugger]], essendo in grado di risolvere più efficacemente eventuali errori annullando immediatamente le modifiche che li hanno causati.<ref>[http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1 ''Stepping Through the Looking Glass: Test-Driven Game Development'']</ref>

Scrivendo i test prima del codice, si utilizza il [[programma (informatica)|programma]] prima ancora che venga realizzato. Ci si assicura, inoltre, che il codice prodotto èsia 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 confidenzafiducia 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 correlateNote ==

<references />

*[[Extreme Programming]]

*[[Unit test]]

*[[Automazione del collaudo del software]]

== Voci correlate ==

==Collegamenti esterni==

* [[Extreme Programmingprogramming]]

*{{en}} [http://www.agiledata.org/essays/tdd.html Introduction to Test Driven Development (TDD)]

* [[en:TestBehavior-driven development]]

* [[Unit test]]

* [[Automazione del collaudo del software]]

* [[You aren't gonna need it]]

== Collegamenti esterni ==

[[Categoria:Metodologie di sviluppo]]

* {{en}}cita [web|http://www.agiledata.org/essays/tdd.html |Introduction to Test Driven Development (TDD)]|lingua=en}}

* {{cita web|1=http://www.agilesherpa.org/agile_coach/engineering_practices/test_driven_development/|2=Test Driven Development|lingua=en|accesso=21 ottobre 2011|urlarchivio=https://archive.is/20120723184333/http://www.agilesherpa.org/agile_coach/engineering_practices/test_driven_development/|dataarchivio=23 luglio 2012|urlmorto=sì}}

[[Categoria:MetodologieMetodologia di sviluppoagile]]

[[bg:Разработка чрез тестове]]

[[cs:Programování řízené testy]]

[[de:Testgetriebene Entwicklung]]

[[en:Test-driven development]]

[[es:Desarrollo guiado por pruebas]]

[[fi:Testivetoinen kehitys]]

[[fr:Test Driven Development]]

[[he:פיתוח מונחה-בדיקות]]

[[ja:テスト駆動開発]]

[[jbo:cipra mukti sampla]]

[[nl:Test-driven development]]

[[no:Testdrevet utvikling]]

[[pl:Test-driven development]]

[[pt:Test Driven Development]]

[[ru:Разработка через тестирование]]

[[sv:Test Driven Development]]

[[uk:Розробка через тестування]]

[[zh:测试驱动开发]]