Non sono un profondo conoscitore delle metodologie agili. Tuttavia la mia impressione è che il TDD sia una delle metodologie applicabili e se si da come per scontato che il TDD sia il miglior metodo sempre e comunque allora certamente quello che dici ha senso.

Ma io credo che in taluni ambiti si possa utilizzare il testing automatico anche per altri scopi e con grande successo, e non con il primo obiettivo di un design efficace. Uno di questi sembra essere il testing delle GUI.

Spesso ci si dimentica che il fine dello Unit Testing è creare un design efficace, mentre la verifica di correttezza è un utile sottoprodotto, come si diceva tempo fa’ sulla lista XP-IT.

Tuttavia è possibile limitare i danni usando certi strumenti e metodologie. Nel web (l’unico GUI testing su cui ho un minimo di esperienza) è molto conveniente l’utilizzo degli identificatori per rendere facilmente tracciabili gli elementi nella pagina. Anche l’uso di CSS rende più scarna e testabile la pagina.

Per quanto riguareda i tool, sicuramente Selenium è ottimo. Si può utilizzare su svariati browser e tramite un plugin per Firefox si possono anche creare delle macro. Una volta salvate in forma di test, sono ottimi punti di partenza per il tuo test case.

In uno dei progetti in cui sono coinvolto adesso, i test automatici coprono un’alta percentuale del codice che è stato scritto in maniera test driven, purtroppo l’interfaccia non è testata, indovina gli unici bug che sono finiti in produzione dov’erano localizzati? Stiamo parlando di mispelling nelle label, piccoli errori nel processo di build che rompe un link, ecc… Tutte cose stupidissime ma percepite in maniera forte dall’utente. Possono anche essere testate manualmente, ma più l’applicazione cresce più ne cresce il costo collegato

@Aniello - In realtà l’UG-Aggregator è stato sviluppato in modo “Test Driven”.

Ovvero: se un pezzo di codice non risulta facilmente testabile (vuoi per come è stato scritto, vuoi per la tecnologia in cui è stato scritto), prima di chiudere il discorso dicendo che costerebbe troppo testarlo, io mi chiederei:
- perchè costa troppo
- se costasse meno lo testerei e perchè
- se posso fare in modo (implementandolo diversamente o cambiando tecnologia) che costi di meno testarlo

Concludo dicendo che è vero che il nostro aggregato all’XPUG non aveva alcuna logica di business, ma ti faccio presente che qui stiamo parlando sopratutto di sostenibilità dello sviluppo del software, della possibilità di un software di evolvere nel tempo, di abbracciare il cambiamento, se non riesci (perchè troppo costoso) a testare un’applicazione banale, questo non ti fa nascere qualche dubbio? A me si, di brutto, infatti l’esperienza all’XPUG mi ha portato un grande insegnamento