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 @ martedì 3 luglio 2007 21.09

Print

Comments on this entry:

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

Left by Roberto Messora at 03/07/2007 21.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 03/07/2007 21.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.

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

Left by Antonio Ganci at 04/07/2007 12.21
Gravatar
E' vero che anche senza utilizzare il TDD si può consegnare del buon software, cosa che facevo anch'io prima.
Non vorrei però che la tecnica di design TDD venisse liquidata superficialmente come una moda passeggera del momento, io credo che chi si occupa di sviluppo software dovrebbe, se ne ha l'opportunità, approfondire l'argomento.
Secondo me quando VS.NET lo supporterà meglio il TDD si diffonderà molto di più di ora.
X Roberto: non mi è chiara questa frase: "nessuno fa TDD puro al 100%, altrimenti si troverebbe nella situazione di dover continuamente reinventare la ruota". Cosa intendi dire?

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

Left by Maccari Claudio at 04/07/2007 21.05
Gravatar
@Roberto
Per carita. Oltre al TDD ci sono altre pratiche altrettanto utili per far emergere il tuo DDD. Parlando di pratiche XP più in generale nel libro di Kent Beck "Extreme Programming Explained" nel capitolo "Primary practices" il Test-First Programming è una delle trecidici 13 pratiche mezionate. Nota anche che c'è un capitolo che si chiama "Corollary practices" che ne propone anche altre.

@Raffaele
Certo che si possono avere buoni risultati anche con altre metodologie.
Ognuno deve adottare trovare quella più "confortevole" e più produttiva per il proprio contesto: se non trovi vantaggi nell'utilizzare unit test durante lo sviluppo mi sembra poco furbo ostinarsi ad utilizzarlo
Comments have been closed on this topic.