Unit Test: o tutto o niente

Da un po' di tempo mi sono appassionato allo Unit Testing (e ultimamente anche al TDD) e mi piace scrivere i test unitari per le applicazioni che realizzo.

Visto che mi piace, mi capita spesso di consigliarlo ai miei clienti e se riesco a convincerli (è una pratica difficile da far accettare) cominciano ad utilizzarli anche loro.
Il problema è che spesso i test vengono scritti male e non coprono tutte le casistiche.

Uno dei grossi vantaggi dello Unit Testing è che puoi fare refactoring al tuo codice con sufficiente disinvoltura sapendo che se si rompe qualcosa viene subito intercettato.
Ma se sono scritti male?
E' come se non ci fossero perché il valore della barra verde è nullo visto che non testa tutto il codice che hai scritto e non sai se è verde perché va tutto bene o perche l'errore è in una parte non coperta da test.
Quindi se si decide di scrivere i test unitari è meglio mettersi d'impegno e scriverli bene.

Un consiglio?

Per far si che questo avvenga in modo naturale basta fare Test Driven Development!

Print | posted on venerdì 8 settembre 2006 17.25

Comments on this post

# re: Unit Test: o tutto o niente

Requesting Gravatar...
Ultimamente anche noi ci muoviamo nella stessa direzione, e direi che gli unit test servono a poco senza controlli sulla copertura del codice. Noi usiamo NUnit e NCover insieme, ritengo che il primo senza il secondo serva a poco, mentre insieme formano una coppia utilissima :)
Left by Wasp on set 08, 2006 5.54

# Re: Unit Test: o tutto o niente

Requesting Gravatar...
il bello di usare TDD è che ti garantisce che una suite eseguita con successo corrisponde a funzionalità del sistema realmente testate. cioè, risolve il problema dei "finti" test, quelli con esiti positivi ma che non significano che il codice sia corretto.

per provare a verificare la bontà dei test esistono alcune possibilità (e direi che sono utili anche senza fare TDD, anzi molto più importanti per il solo unit-testing). la prima è usare la copertura (es: con NCover), ma anche questa non basta (nel caso di test scritti *dopo*). esiste un'altro approccio, molto più "pragmatico", che è quello dell'analisi mutazionale.

lascio il link di Jester, il tool relativo alla mutational analysis per Java (in .NET esiste il port fatto da Nester, ma è ancora in fase embrionale e pare senza aggiornamenti da lungo tempo):

http://jester.sourceforge.net/
http://nester.sourceforge.net/

un approccio davvero interessante!
ciao
-papo-
Left by papo on set 11, 2006 1.30

Your comment:

 (will show your gravatar)
 
Please add 8 and 3 and type the answer here: