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!