Fai rotolare la palla su TDD

Incorporazione diretta di TDD in piena regola in un codice legacy, il progetto di manutenzione è una vendita molto difficile. Un approccio che ho visto funzionare molto bene è questo. Per ogni bug che arriva, crea un test non unitario automatico che mostri il bug. Con "non-unità", intendo qualcosa che può toccare molte parti del sistema, colpire database e file system, ecc. Ma con "automatizzato" intendo corse senza interazione umana. Questo è il tipo di test che vorrete nella vostra suite di regressione in ogni caso. Scriverlo fa un sacco di cose: ti fa rendere testabile il codice, anche se a quel livello molto approssimativo, e ti espone alla costellazione di codice che potrebbe avere qualcosa a che fare con il bug, quindi ti istruisce e ti informa materiale molto specifico.

Ma non è la fine. Una volta che questo test è in esecuzione e in esecuzione in rosso (a dimostrazione dell'errore nel codice), prenditi il tempo necessario per capire cosa non va (devi farlo in ogni caso). Ma non aggiustarlo ancora. Una volta che hai isolato quello che pensi sia il problema, scrivi un test unit che mostri quel problema. Ora hai qualcosa su cui puoi lavorare (e, non a caso, potresti aver dovuto ridimensionare un po 'di più verso una testabilità ancora maggiore). Risolvi il bug. Guarda il test pass per l'unità. Forse arricchiscilo con alcuni casi limite; prendi quella unità - quella che ti è costata solo due settimane - solida, pulita e ben collaudata. Ora esegui il test di regressione e guardalo passare (ovviamente, se non funziona, hai ancora un po 'di ricerca e lavoro a livello di unità da fare - iterare fino a quando, anche, sta passando). Controlla tutto. Che cosa hai? Test di regressione per codice precedentemente fallito. Test unitari per codice precedentemente fallito. Codice funzionante che stava fallendo. Codice progettato meglio, perché ora è più testabile di quanto non fosse. Migliore fiducia nella tua base di codice, una migliore comprensione di una delle parti più malvagie del tuo codice.

Non è TDD "puro". Ma dimostra i risultati, rapidamente, e migliora la qualità del tuo codice nel tempo. I risultati ti aiuteranno a ottenere un buy-in di gestione.

Nella mia azienda, ho seguito il metodo "only a grunt" di JoelOnSoftware e ho iniziato a scrivere test unitari ogni volta che normalmente avrei semplicemente hackerato una specie di applicazione console da buttare via. Ho iniziato a fare le cose molto più velocemente con rilasci più stabili e mi sono fatto notare. Quando ho chiesto cosa stavo facendo, ho spiegato che avevo iniziato a utilizzare TDD e scrivere test di unità ogni volta che modificavo il vecchio codice o scrivevo un nuovo codice. I miei colleghi sviluppatori iniziarono a incuriosirsi e iniziarono a usare test unitari integrati. Non credo che ci sia una buona argomentazione per scrivere test per il codice legacy, ma se si riesce a dimostrare che scrivere test automatici è più veloce e più conveniente di scrivere spaghetti per la console, allora gli sviluppatori intelligenti seguiranno lungo. Gli altri vantaggi che si traducono in un software di qualità superiore saranno presenti anche qui, ma la chiave per ottenere l'accesso degli sviluppatori sta dimostrando che semplifica la loro vita. Per quanto riguarda il business sign on, il fatto che ciò comporterà un software migliore e probabilmente impiegherà meno tempo di spedizione 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 della qualità si aggiungono al denaro del cliente. E qui ci sono i miei pensieri su come puoi convincere il tuo manager e il tuo cliente:

• Raccogli le metriche dei bug che avevi aggiustato dire negli ultimi 6 mesi e il tempo minimo, medio e massimo necessario per correggere un bug.
• Per tutti i bug corretti o contestati, prova a scrivere test unitari che coprano quelle aree.
• Per i bug su cui stai lavorando e quelli su cui lavorerai, prova a scrivere dei test unitari attorno a quelle aree anche prima di apportare modifiche. Quindi scrivi il codice per capire la causa e risolverlo. Vedi se rompe qualcuno dei tuoi casi di test esistenti. In caso affermativo, spiega e aiuta i tuoi colleghi a comprendere l'importanza dei Test delle unità.
• Una volta che tutti gli sviluppatori hanno compreso l'importanza dei Test delle unità, chiedi loro di continuare a fare ciò che hai fatto per così tanti giorni / settimane.
• Con il passare del tempo, la produttività dei team dovrebbe migliorare tanto che sia il tuo manager sia i clienti rimarrebbero sorpresi dal tasso di miglioramento della produttività e dalla qualità del codice. È un po 'che richiede tempo, ma vale la pena provare.

C'è un altro modo, ed è quello di provare ad unirti al tuo manager per partecipare alle Conferenze Agili che accadono intorno. Certamente dovrebbe valerne la pena.

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

E sappi cosa Unit test dopo aver scritto il codice non è in realtà TDD, ma che può sempre essere il primo passo. Si adatta così bene qui almeno.

Ti auguro buona fortuna e successo!