Unit testing: differenze tra le versioni

Versione delle 10:41, 30 gen 2024

Versione attuale delle 09:56, 17 giu 2025

(4 versioni intermedie di 2 utenti non mostrate)

Riga 1:

{{F|informaticaingegneria del software|gennaio 2024}}

In [[ingegneria del software]], per '''''unit testing''''', '''test unitario'''<ref name="glossario">{{Cita web|url=https://analisi-disegno.com/testing/glossario-testing/|titolo=Glossario del Testing|accesso=9 novembre 2022-11-09}}</ref> o '''collaudo unitario''', si intende l'attività di 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 [[Collaudo del software|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"/> Lo unit testing è tipicamente [[Automazione del collaudo del software|automatico]], ed è implementato utilizzando librerie predisposte per ciascun linguaggio di programmazione (per esempio JUnit in Java, da 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à.

Riga 33:

Come ogni forma di testing, anche lo Unit Testing non può certificare 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 dalle 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 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.

Riga 43:

== Applicazioni ==

===Extreme Programming===

{{Vedi anche|Extreme programming}}

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.

Riga 50 ⟶ 51:

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===

Riga 56 ⟶ 57:

Normalmente lo unit testing è automatizzato, ma può anche essere eseguito manualmente. Non c'è alcuna raccomandazione in proposito da parte dello [[IEEE]]. L'approccio manuale può richiedere la documentazione dei passi necessari per l'esecuzione dello unit test. In ogni caso, lo scopo dello unit test è quello di isolare un modulo e certificarne la correttezza. L'automatizzazione, a differenza del test manuale, è un modo efficiente per raggiungere questi obbiettivi e portare i benefici descritti.

Con l'approccio automatico, per realizzare il completo isolamento del modulo da testare, il codice funzionale è testato al di fuori del suo ambiente naturale, in un apposito [[framework]]. Questo approccio ha il pregio di evidenziare dipendenze non richieste del modulo in esame dagli altri.

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.

Riga 78 ⟶ 79:

==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.softdevarticlesxprogramming.com/modules/weblinks/viewcattestfram.php?cid=34htm |titolo=UnaL'originale listaunit testing di articoliKent sull'unitBeck per testingil framework(in inglese) |accesso=13 ottobre 2007 |urlarchivio=https://web.archive.org/web/2007101313275120150315073817/http://softdevarticleswww.xprogramming.com/modules/weblinks/viewcattestfram.php?cid=34|dataarchivio=13htm# ottobre 2007|urlmorto=sì }}

* {{cita web | 1 url= http://shebanationwww.softdevarticles.com/2007modules/08weblinks/21/a-brief-history-of-test-frameworks/ viewcat.php?cid=34|titolo=Una 2lista =di Laarticoli storia dellsull'unit testing per il framework di Andrew Shebanow(in inglese) | accesso = 13 ottobre 2007 | urlarchivio = https://web.archive.org/web/2007101314140220071013132751/http://shebanationsoftdevarticles.com/2007modules/08weblinks/21/a-brief-history-of-test-frameworks/ | dataarchivio viewcat.php?cid= 13 ottobre 2007 34| urlmorto = sì }}

* {{cita web | url = http://shebanation.com/2007/08/21/a-brief-history-of-test-frameworks/ | titolo = 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/ | urlmorto = sì }}

{{Portale|informatica|ingegneria}}

[[Categoria:Ingegneria del software]]