Unit testing: differenze tra le versioni

Versione delle 17:19, 13 nov 2018

Versione attuale delle 07:29, 12 lug 2024

(16 versioni intermedie di 11 utenti non mostrate)

Riga 1:

{{F|informatica|gennaio 2024}}

In [[ingegneria del software]], per '''unit testing''' ('''testing d'unità''' o '''testing unitario'''<ref name="glossario">[http://www.analisi-disegno.com/testing/glossario-testing/ Glossario sul software testing]</ref>) si intende l'attività di ''testing''<ref>Nella terminologia inglese, diffusa anche nella letteratura italiana ma non sempre adottata in modo coerente, la parola ''testing'' indica l'attività di prova nel suo insieme; una singola prova viene chiamata ''test''.</ref> (prova, collaudo) di singole unità [[software]]. Per unità si intende normalmente il minimo componente di un [[programma (informatica)|programma]] dotato di funzionamento autonomo; a seconda del [[paradigma di programmazione]] o [[linguaggio di programmazione]], questo può corrispondere per esempio a una singola [[funzione (informatica)|funzione]] nella [[programmazione procedurale]], o una singola [[classe (informatica)|classe]] o un singolo [[metodo (programmazione)|metodo]] nella [[programmazione a oggetti]].

In [[ingegneria del software]], per '''''unit testing''' ('''testing, d'unità''' o '''testingtest unitario'''<ref name="glossario">[http{{Cita web|url=https://www.analisi-disegno.com/testing/glossario-testing/ |titolo=Glossario suldel software testing]Testing|accesso=2022-11-09}}</ref>) sio intende l'attività di''collaudo unitario''testing''<ref>Nella terminologia inglese, diffusasi anche nella letteratura italiana ma non sempre adottata in modo coerente, la parola ''testing'' indicaintende l'attività di prova nel suo insieme; una singola prova viene chiamata ''test''.</ref> (prova, collaudo) di singole unità di un [[software]]. Per unità si intende normalmente il minimo componente di un [[programma (informatica)|programma]] dotato di funzionamento autonomo; a seconda del [[paradigma di programmazione]] o [[linguaggio di programmazione]], questo può corrispondere per esempio a una singola [[funzione (informatica)|funzione]] nella [[programmazione procedurale]], o una singola [[classe (informatica)|classe]] o un singolo [[metodo (programmazione)|metodo]] nella [[programmazione a oggetti]].

Lo ''unit testing'' viene normalmente eseguito dagli [[Sviluppatore software|sviluppatori]], e può essere occasionalmente [[glass box testing|glass box]], ovvero essere esplicitamente basato sulla conoscenza dell'architettura e del funzionamento interno di un componente oltre che sulle sue funzionalità esternamente esposte.<ref name="glossario"/> Come le altre forme di testing, lo unit testing può variare da completamente "manuale" ad [[Automazione del collaudo del software|automatico]]. Specialmente nel caso dello unit testing automatico, lo sviluppo dei [[caso di test|test case]] (cioè delle singole procedure di test) può essere considerato parte integrante dell'attività di sviluppo (per esempio, nel caso dello [[test driven development|sviluppo guidato da test]]).

Lo ''unit testing'' viene normalmente eseguito dagli [[Sviluppatore software|sviluppatori]], e può essere occasionalmente [[glassCollaudo boxdel testingsoftware|glass box]], ovvero essere esplicitamente basato sulla conoscenza dell'architettura e del funzionamento interno di un componente oltre che sulle sue funzionalità esternamente esposte.<ref name="glossario"/> Come le altre forme di testing, loLo unit testing può variare da completamente "manuale"è adtipicamente [[Automazione del collaudo del software|automatico]]., ed Specialmenteè nelimplementato casoutilizzando dellolibrerie unitpredisposte testingper automaticociascun linguaggio di programmazione (per esempio JUnit in Java, loda cui prendono spunto anche la maggior parte delle altre librerie software di Unit Testing). Lo sviluppo dei [[caso di test|test case]] (cioè delle singole procedure di test) può essere considerato parte integrante dell'attività di sviluppo (per esempio, nel caso dello [[test driven development|sviluppo guidato da test]]) ed è una best practice raccomandata sempre durante lo sviluppo software in quanto è in grado di verificare il buon funzionamento di ogni singola componente del software in poco tempo e con grande affidabilità.

==Benefici==

== Vantaggi ==

Lo scopo 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 sorgente|codice]] funziona correttamente, con importanti vantaggi:

Lo scopo 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 sorgente|codice]] funziona correttamente, con importanti vantaggi:

===Semplifica le modifiche===

Line 25 ⟶ 27:

I 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 causa di successive modifiche del codice non documentate.

==Limiti==

==Separazione dell'interfaccia dall'implementazione==

Poiché alcune classi possono far riferimento ad altre, il test di una classe spesso si propaga alle altre. Un esempio è una classe che interagisce con un [[database]]: testare la classe spesso implica la scrittura del codice che interagisce con il database. Questo è un problema perché lo unit test non dovrebbe mai varcare i confini della classe. La conseguenza è che il programmatore, nel progettare lo unit testing, impara ad isolare la classe da analizzare, individuando l'interfaccia con il database ed implementandola con un [[mock object]], una simulazione dell'oggetto reale che può essere effettuata in condizioni controllate. L'effetto è un test più approfondito e quindi uno unit testing di qualità più elevata.

==Limitazioni dello unit testing==

In generale il testing non riesce ad identificare tutti gli errori in un programma e lo stesso vale per lo Unit Testing che, analizzando per definizione le singole unità, non può identificare gli errori di integrazione, problemi legati alla performance e altri problemi legati al sistema in generale. Lo unit testing è più efficace se utilizzato in congiunzione con altre tecniche di testing del software.

Line 39 ⟶ 37:

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

== Separazione dell'interfaccia dall'implementazione ==

==Applicazioni==

Poiché alcune classi possono far riferimento ad altre, il test di una classe spesso si propaga alle altre. Un esempio è una classe che interagisce con ununa [[databasebase di dati]]: testare la classe spesso implica la scrittura del codice che interagisce con il database. Questo è un problema perché lo unit test non dovrebbe mai varcare i confini della classe. La conseguenza è che il programmatore, nel progettare lo unit testing, impara ad isolare la classe da analizzare, individuando l'interfaccia con il database ed implementandola con un ''[[mock object]]'', una simulazione dell'oggetto reale che può essere effettuata in condizioni controllate. L'effetto è un test più approfondito e quindi uno unit testing di qualità più elevata.

== Applicazioni ==

===Extreme Programming===

{{Vedi anche|Extreme programming}}

Lo unit testing è la parte fondamentale dell'''[[Extremeextreme Programmingprogramming]]'' (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 Svilupposviluppo Guidatoguidato dalda Testtest (TDD, ''[[Testtest Drivendriven Developmentdevelopment]]''). 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 affinché 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.

Ovviamente questa tecnica è applicabile solo alle unità deterministiche del codice, mentre tutto il codice di integrazione o non deterministico, ad esempio il codice che si basa sulle interazioni utente, le basi dati, l'interazione con il sistema operativo o le periferiche, le connessioni di rete, non può essere testato in questa modalità. In certi casi si usano delle interfacce simulate (mock) per emulare l'interazione con elementi non deterministici (ad esempio simulando un possibile database o il comportamento di un utente) ma per ovvie ragioni questo tipo di testing non è né completo, né totalmente realistico.

===Tecniche===

Line 56 ⟶ 61:

In un framework automatizzato lo sviluppatore codifica i casi da testare in modo che verifichino la correttezza del modulo e durante l'esecuzione venga riportato l'eventuale fallimento di ogni test. In alcuni casi di fallimento di test critici, l'intera procedura di test viene fermata.

La conseguenza dello unit testing è un approccio alla programmazione che favorisce la scrittura di codice in moduli indipendenti ed interoperanti, che a sua volta contribuisce, insieme ai ''[[Designdesign pattern]]'' e ad altre pratiche comuni alla realizzazione del miglior codice possibile.

===Unit testing framework===

Line 71 ⟶ 76:

* [[Regression testing]]

* [[Software testing]]

* [[System testing]]

* [[JUnit]]

==Collegamenti esterni==

* {{FOLDOC||unit testing}}

* {{cita web |1=http://www.xprogramming.com/testfram.htm |2=L'originale unit testing di Kent Beck per il framework(in inglese) |accesso=13 ottobre 2007 |urlarchivio=https://web.archive.org/web/20150315073817/http://www.xprogramming.com/testfram.htm# |dataarchivio=15 marzo 2015 |urlmorto=sì }}

* {{cita web|url=http://www.softdevarticles.com/modules/weblinks/viewcat.php?cid=34|titolo=Una lista di articoli sull'unit testing(in inglese)|accesso=13 ottobre 2007|urlarchivio=https://web.archive.org/web/20071013132751/http://softdevarticles.com/modules/weblinks/viewcat.php?cid=34|dataarchivio=13 ottobre 2007|urlmorto=sì}}

* {{cita web | 1 = http://shebanation.com/2007/08/21/a-brief-history-of-test-frameworks/ | 2 = La storia dell'unit testing per il framework di Andrew Shebanow(in inglese) | accesso = 13 ottobre 2007 | urlarchivio = https://web.archive.org/web/20071013141402/http://shebanation.com/2007/08/21/a-brief-history-of-test-frameworks/ | dataarchivio = 13 ottobre 2007 | urlmorto = sì }}

* [https://www.paolodellaguzzo.com/blog/2017/12/06/come-scrivere-i-test-in-javascript/ Unit Testing in JavaScript], su paolodellaguzzo.com

{{Portale|informatica|ingegneria}}

[[Categoria:Ingegneria del software]]