Unit testing: differenze tra le versioni

Versione delle 03:38, 20 feb 2012

Versione delle 16:39, 27 mar 2012

Riga 1:

Nella [[Programmazione_(informatica)|programmazione informatica]], lo '''unit testing''' ('''test d'unità''') è una procedura usata per verificare singole parti di un [[codice sorgente]] . Per unità si intende genericamente la minima parte testabile di un [[codice sorgente]]: nella [[programmazione procedurale]] un'unità può rappresentare un singolo programma, funzione, procedura, etc.; nella [[Programmazione orientata agli oggetti]], la più piccola unità può essere il [[metodo (programmazione)|metodo]].

Lo Unit Testing si articola in ''[[:en:test case|test case]]'' ciascuno dei quali dovrebbe essere indipendente dagli altri. Lo Unit Testing viene normalmente eseguito dagli [[Sviluppatore software|sviluppatori]], non da [[utenti finali]].

==Benefici==

Lo scopo dell'dello Unit testing è quello di verificare il corretto funzionamento di parti di programma permettendo così una precoce individuazione dei [[bug]]. Uno unit testing accurato può dare una prova certa se un pezzo di codice funziona correttamente, con importanti vantaggi:

===Semplifica le modifiche===

Lo unit testing facilita la modifica del codice del modulo in momenti successivi ([[refactoring]]) con la sicurezza che il modulo continuerà a funzionare correttamente. Il procedimento consiste nello scrivere [[:en:test case]] per tutte le funzioni e i metodi, in modo che se una modifica produce un fallimento del test, si possa facilmente individuare la modifica responsabile.

Unit test già predisposti semplificano la vita al programmatore nel controllare che una porzione di codice stia ancora funzionando correttamente. Un buon unit testing produce [[:en:test case]] che coprano tutti i percorsi del codice dell'unità, con particolare attenzione alle condizioni nei cicli (test sugli ''if'', ''while'', ''for'').

In sistemi con unit testing continuo, tali test sono in grado di garantire l'automatica integrità del codice ad ogni modifica.

Riga 23:

Lo unit testing fornisce una documentazione "viva" del codice, perché è intrinsecamente un esempio di utilizzo dell'[[Application programming interface|API]] del modulo.

I [[:en:test case|test case]] incorporano le caratteristiche critiche per il successo di un'unità di codice. Tali caratteristiche indicano l'uso appropriato dell'unità e i comportamenti errati che devono essere identificati nel suo funzionamento. Pertanto lo unit testing documenta tali caratteristiche, sebbene in molti ambienti questi non possono costituire la sola documentazione necessaria. In compenso, la tradizionale documentazione diventa spesso obsoleta a cause di successive modifiche del codice non documentate.

==Separazione dell'interfaccia dall'implementazione==

Riga 35:

Come ogni forma di testing, anche lo Unit Testing non può individuare l'assenza di errori ma può solo evidenziarne la presenza.

Il testing del software è un problema di matematica combinatoria. Per esempio, ogni test booleano richiede almeno due test, uno per la condizione di "vero" e uno per quella di "falso". Si può dimostrare che, per ogni linea di codice funzionale, siano necessarie dalladalle 3 alle 5 linee di codice per il test. È quindi irrealistico testare tutte le possibili combinazioni di input di qualsiasi codice non banale senza un tool apposito di generazione di casi di test.

Per ottenere gli sperati benefici dallo unit test, è richiesto un rigoroso senso di disciplina durante tutto il processo di sviluppo. È essenziale mantenere traccia non solo dei test che non stati sviluppati ed eseguiti, ma anche di tutte le modifiche effettuate al codice funzionale dell'unità in esame e di tutte le altre. L'uso di un sistema di [[controllo versione]] è essenziale. Se una versione successiva di una unità fallisce un test che aveva passato in precedenza, il sistema di controllo versione permette di evidenziare le modifiche al codice intervenute nel frattempo.

Riga 45:

Lo unit testing è la parte fondamentale dell'[[Extreme Programming]] (XP), che si basa su uno [[unit testing framework]], che può essere fornito da terze parti o creato all'interno del gruppo di sviluppo.

L'Extreme Programming usa la creazione di unit test per lo Sviluppo Guidato dal Test (TDD, [[Test Driven Development]]). Lo sviluppatore scrive uno unit test che evidenzi una funzionalità richiesta dalle specifiche o un difetto possibile. Il test può fallire perché la funzionalità non è stata ancora implementata o perché il difetto cercato è effettivamente verificato. Quindi lo sviluppatore scrive il codice funzionale più semplice possibile affiché il test sia eseguito con successo.

Tutte le classi sono testate in questo modo e lo sviluppatore rilascia il codice di test insieme al codice funzionale da esso testato. La XP, con uno unit testing approfondito, presenta tutti i benefici descritti sopra e i test sono utilizzati successivamente come test di regressione.

Riga 63:

Esistono framework sviluppati per lo unit testing di una miriade di linguaggi. È generalmente possibile realizzare lo unit testing senza il supporto di uno specifico framework, scrivendo il codice che testi il modulo e che implementi meccanismi quali le asserzioni, le eccezioni o le uscite anticipate per segnalare i fallimenti.

Questo approccio è prezioso perché semplifica l'adozione dello unit testing, ma è anche limitato dall'assenza di molte funzionalità avanzate dei framework disponibili.

Per un elenco dei framework disponibili vedere [[:en:List_of_unit_testing_frameworks|List of unit testing frameworks]].

==Voci correlate==