Test driven development: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Recupero di 1 fonte/i e segnalazione di 0 link interrotto/i.) #IABot (v2.0.9.5 |
Archive.today ___domain not accessible from Italy (x1)) #IABot (v2.0.9.5) (GreenC bot |
||
| (Una versione intermedia di un altro utente non mostrate) | |||
Riga 15:
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.
Riga 46:
== Collegamenti esterni ==
* {{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.
[[Categoria:Metodologia agile]]
| |||