Unit testing non è sicurmanente la panacea di tutti i mali!

Oddio cosa ho scritto. Ma in fondo è solo la pura verità.

Stuzzicato dal post di Raffaele non ho potuto trattenermi dal postare anch'io e spendere 2 parole sull'argomento. Al mio commento Raffaele ha risposto :

"Unit Testing non può essere una base per validare un software.
È solo uno dei tanti sistemi che può rivelarsi più o meno utile a seconda dei casi"

Io qui ribatto con: Sicuramente usare solo unit test non basta, ma se parliamo di test ce ne sono diversi tipi e riuscire ad automatizzarli invece che affidarsi ad un tester ha dei vantaggi oggettivi. Certamente non sempre è una attività semplice ma ci sono sempre più strumenti utili per riuscirci. 

Oltre ad altri commenti si è aggiunto un post di Mario che ribatte alcune delle mie affermazioni espresse nel commento al post di Raffaele. (@Mario: il fatto di "puntare il dito direttamente contro di me" mi fa solo che piacere :D )

Passo passo riprendo alcune delle affermazioni di Mario ed esprimo alcune precisazioni:

"Testare a posteriori [...] serve se si evidenzia un bug nel software"

Certo ma okkio che se riscontriamo un bug, scriviamo un test che riproduce l'errore e poi fissiamo il bug nel codice stiamo facendo TDD. La definizione di Wikipedia dice proprio questo: prima ho scritto un test e poi il codice in modo tale da non far fallire il test.

"Il codice non è di qualità solo perchè è stato scritto un test che viene superato"

Qui probabilmene c'è un'ìncompresione, io scrivo TDD e tu mi rispondi dicendo unit test. Scrivere codice in TDD mi permette di far emerge il mio DDD e la mia architettura in maniera evolutiva. Il test mi garantisce che venga scritto codice che fa quello che mi serve e che il suo comportamento, a seguito di modifiche, rimanga invariato.

"Metodologie Agili non significano solo TDD e pair programming"

Beh chi ha mai detto il contrario ? Sono solo alcune delle pratiche utilizzate da chi usa XP. Sono un buon inizio per "diventare agili"

"Cosa significa guadagnare la fiducia del committente? Significa fargli vedere 2400 cerchiolini verdi che si accendono oppure significa che dopo aver consegnato il prodotto in fase finale, negli anni a seguire questo continua a funzionare egregiamente senza bug o errori "strani"?"

Significa consegnare già dalla prima release codice funzionante, significa mantenerlo tale con l'aumentare delle funzionalità. Significa non basarsi SOLO sui tester per la verifica del mio codice. Per inciso al cliente non interessa che metodologia usi per sviluppare software, interessa avere qualcosa che risolva i suoi problemi quando si presentano.

Ps: se qualcuno domani è al workshop di UGISS ed ha voglia di affrontare l'argomento si faccia avanti!

 

posted @ mercoledì 4 luglio 2007 00:09

Print

Comments on this entry:

# re: Unit testing non è sicurmanente la panacea di tutti i mali!

Left by Roberto Messora at 04/07/2007 00:23
Gravatar
Mi raccomando però a specificare bene le frasi, quando dici che TDD ti aiuta a far emergere il DDD, aggiungi anche che non è l'unico modo. TDD è una metodologia, ma per raggiungere gli obiettivi che citi, non è la sola.
nessuno mette in dubbio che il TDD sia un modo per arrivare a tali obiettivi, ma non è l'unico...
anche perchè permettimi una considerazione: nessuno fa TDD puro al 100%, altrimenti si troverebbe nella situazione di dover continuamente reinventare la ruota. ma non solo, spesso il design, anche dopo aver scritto parte della suite di regressione, viene modificato dall'attività di refactoring che a volte porta pure a cambiare i test già scritti.
saluti

# re: Unit testing non è sicurmanente la panacea di tutti i mali!

Left by Raffaele Rialdi at 04/07/2007 00:49
Gravatar
Quoto Roberto e aggiungo che con le metodologie tradizionali è assolutamente possibile eseguire consegne con soddisfazione del cliente per con pochi o zero bug.
Ho come abitudine da tantissimi anni quella di fare consegne continue al cliente in tempi molto brevi e la metodologia classica non mi ha mai tradito.
Comments have been closed on this topic.