Fai rotolare la palla su TDD

Faccio parte di un team di sviluppatori che lavora con molti altri team per mantenere e migliorare un'applicazione in uso da almeno 15 anni. Quando fu costruito e progettato per la prima volta, TDD era inaudito.

L'applicazione è abbastanza stabile e raramente si verifica un bug che interrompe lo spettacolo, ma facciamo una media di circa uno o due bug a settimana che riducono notevolmente la qualità del servizio. Questi bug impiegano un'eternità a trovare e correggere, in gran parte a causa del puntamento del dito, e l'unico test che abbiamo è il test dell'interfaccia. Poiché c'è molto tempo sprecato a cercare il bug prima che possa essere risolto, io e un altro sviluppatore abbiamo in programma di proporre Test Driven Development. È in arrivo una nuova revisione e vorremmo vedere i test di unità quasi completi eseguiti sui nuovi moduli, prevediamo anche di suggerire di costruire unità di test per qualsiasi codice che dobbiamo modificare che sia legacy (ad esempio, correzione di bug o implementazione di funzionalità ), ma per non perdere tempo a sviluppare casi di test per codice che non ha causato problemi.

A me sembra ragionevole. Questo mese abbiamo riscontrato un bug che ha richiesto più di due settimane per essere risolto, ma avrebbe potuto essere identificato prima di essere distribuito se fosse stato eseguito il test dell'unità. Ma per i nostri manager sembra che spenderanno più soldi.

Come convincere i nostri clienti a voler spendere i soldi per test unitari e sviluppo guidato dai test? Ci sono studi che mostrano il ROI dei test unitari?

Incorporazione diretta di TDD in piena regola in un codice legacy, il progetto di manutenzione è una vendita molto dura. Un approccio che ho visto funzionare molto bene è questo. Per ogni bug presente, crea un test automatico non unitario che dimostri il bug. Per "non unità" intendo qualcosa che può toccare molte parti del sistema, colpire database e filesystem, ecc., Ma per "automatizzato" intendo che funziona senza interazione umana. Questo è il tipo di test che vorrai nella tua suite di regressione in ogni caso. Scriverlo compie molte cose: ti rende testabile il codice, anche se a quel livello molto grossolano, e ti espone alla costellazione di codice che potrebbe avere qualcosa a che fare con il bug, quindi ti educa e ti informa su materiale molto specifico pertinente.

Ma questa non è la fine. Una volta che questo test è in esecuzione e diventa rosso (dimostrando l'errore nel codice), prenditi il ​​tempo per capire cosa c'è che non va (devi farlo, in ogni caso). Ma non aggiustarlo ancora. Dopo aver isolato ciò che pensi sia il problema, scrivi un'unitàtest che dimostra quel problema. Ora hai qualcosa con cui puoi lavorare (e, per inciso, potresti aver dovuto rifattare un po 'di più verso una testabilità ancora maggiore). Risolvi il bug. Guarda il test unit test. Magari si arricchisce con alcuni casi limite; prendi quell'unità - quella che ti è costata solo due settimane di tempo - solida, pulita e ben testata. Ora esegui il test di regressione e guardalo passare (ovviamente, in caso contrario, hai ancora un po 'di ricerca e lavoro a livello di unità - itera fino a quando anche questo non passa). Controlla tutto. Cosa hai? Test di regressione per codice precedentemente non riuscito. Test unitari per codice precedentemente fallito. Codice funzionante che non funzionava. Codice progettato meglio, perché ora è più testabile di quanto non fosse. Maggiore fiducia nella tua base di codice,

Non è "puro" TDD. Dimostra rapidamente i risultati e migliora la qualità del codice nel tempo. I risultati ti aiuteranno a ottenere un buy-in da parte della direzione.

Nella mia azienda, ho appena scelto il metodo "solo un grugnito" di JoelOnSoftware e ho iniziato a scrivere test unitari ogni volta che avrei semplicemente hackerato insieme una sorta di applicazione console da buttare via. Ho iniziato a fare le cose molto più velocemente con versioni più stabili e sono stato notato per questo. Quando mi è stato chiesto cosa stavo facendo, ho spiegato che avevo iniziato a usare TDD e scrivere test unitari ogni volta che avevo modificato il vecchio codice o scritto un nuovo codice. I miei colleghi sviluppatori hanno iniziato a incuriosirsi e hanno iniziato a utilizzare autonomamente i test unitari integrati. Non credo che ci sia una buona argomentazione per scrivere test per il funzionamento del codice legacy, ma se riesci a sostenere che scrivere test automatici è più veloce e più conveniente che scrivere spaghetti per console, allora seguiranno gli sviluppatori intelligenti.Gli altri vantaggi che si traducono in un software di qualità superiore saranno anche lì, ma la chiave per ottenere l'accesso degli sviluppatori è dimostrare che semplifica la vita. Per quanto riguarda gli affari, il fatto che si tradurrà in un software migliore e probabilmente impiegherà meno tempo a spedire rispetto a prima dovrebbe essere più che sufficiente per convincerli.

Prima di tutto, il tuo atteggiamento e il tuo senso di sincerità per il valore di qualità aggiunto al denaro del cliente dovrebbero essere apprezzati. Ed ecco i miei pensieri su come convincere il tuo manager e cliente:

• Raccogli le metriche dei bug che stavi correggendo diciamo negli ultimi 6 mesi e il tempo minimo, medio e massimo impiegato per correggere un bug.
• Per tutti i bug risolti o contestualizzati, prova a scrivere unit test relativi a tali aree.
• Per i bug su cui stai lavorando e quelli su cui lavorerai, prova a scrivere test unitari in quelle aree anche prima di apportare modifiche. Quindi scrivere il codice per capire la causa e risolverlo. Vedi se si rompe uno dei tuoi casi di test esistenti. In caso affermativo, spiega e aiuta i tuoi colleghi a comprendere l'importanza dei test unitari.
• Una volta che tutti gli sviluppatori hanno capito l'importanza dei test unitari, chiedi loro di continuare a fare quello che hai fatto per così tanti giorni / settimane.
• Col passare del tempo, la produttività dei team dovrebbe migliorare nella misura in cui sia il manager che i clienti rimarranno sorpresi dal tasso di miglioramento della produttività e dalla qualità del codice. È un po 'di tempo, ma vale la pena provare.

C'è un altro modo, ed è provare a unirti al tuo manager per partecipare alle Conferenze Agili che accadono in giro. Vale sicuramente la pena partecipare.

Se pensi che nulla funzioni, vai avanti ... unisciti al posto che fa per te. Candidamente, questo è quello che ho fatto. Quando tutto fallì, andai avanti;)

E sapere quali test unitari dopo aver scritto il codice non sono proprio TDD, ma questo può sempre essere il primo passo. Si adatta così bene qui almeno.

Ti auguro buona fortuna e successo!