L'aggiunta di unit test ha senso per il noto codice legacy?

• Sto parlando di unit test in senso TDD. (Non "integrazione" automatizzata, o come ti piace chiamarlo test.)
• Codice legacy come in: (C ++) codice senza test. (vedi: Michael Feathers ' lavora in modo efficace con il codice legacy )
• Ma anche il codice legacy come in: codice con cui il nostro team ha lavorato negli ultimi 10-5 anni, quindi molto spesso abbiamo una buona idea di dove mettere le cose per cambiare qualcosa.
• Disponiamo di test unitari (tramite Boost.Test) per alcuni moduli che sono arrivati ​​in seguito o si sono adattati "in modo naturale" ai test unitari (contenitori specifici per app comuni, stringhe, aiutanti di rete, ecc.)
• Non disponiamo ancora di test di accettazione automatici adeguati.

Ora, recentemente ho avuto il "piacere" di implementare 3 nuove funzionalità rivolte all'utente.

Ognuno di questi mi ha richiesto circa 1-2 ore per aggiornarmi con le parti di codice che dovevo cambiare, 1-2 ore per implementare il (piccolo) codice che avevo bisogno di cambiare e altre 1-2 ore per assicurarmi che l'app corse correttamente dopo e fece come doveva fare.

Ora ho davvero aggiunto poco codice. (Penso che un metodo e alcune linee telefoniche per ogni funzione.)

La stesura di questo codice (tramite uno dei metodi suggeriti in WEwLC ), in modo che un test unitario avesse senso (e non fosse una tautologia completa) avrebbe richiesto facilmente altre 2-4 ore, se non di più. Ciò avrebbe aggiunto il 50% -100% di tempo a ciascuna funzionalità, senza alcun vantaggio immediato

1. Non avevo bisogno del test unitario per capire qualcosa sul codice
2. Il test manuale è lo stesso lavoro, poiché devo ancora verificare se il codice è integrato correttamente nel resto dell'app.

Concesso, se , in seguito, "qualcuno" è arrivato e ha toccato quel codice, teoricamente potrebbe trarre qualche beneficio da quel test unitario. (Solo teoricamente, poiché quell'isola testata di codice vivrebbe in un oceano di codice non testato.)

Quindi, "questa volta" ho scelto di non fare il duro lavoro di aggiungere un test unitario: le modifiche al codice per ottenere quelle cose sotto test sarebbero state significativamente più complesse delle modifiche al codice per ottenere la funzionalità correttamente (e pulita).

È qualcosa di tipico per il codice legacy fortemente accoppiato? Sono pigro / stabiliamo le priorità sbagliate come squadra? O sono prudente, testando solo cose in cui il sovraccarico non è troppo elevato?

Devi essere pragmatico su queste situazioni. Tutto deve avere un valore commerciale, ma l'azienda deve fidarsi di te per giudicare quale sia il valore del lavoro tecnico. Sì, c'è sempre un vantaggio nell'avere test unitari, ma è abbastanza grande da giustificare il tempo impiegato?

Discuterei sempre su un nuovo codice ma, su un codice legacy, devi fare una chiamata di giudizio.

Ti trovi spesso in quest'area di codice? Quindi c'è un caso di miglioramento continuo. Stai apportando un cambiamento significativo? Quindi c'è un caso che è già un nuovo codice. Ma se stai creando un codice di una riga in un'area complessa che probabilmente non verrà toccata di nuovo per un anno, ovviamente il costo (per non parlare del rischio) della riprogettazione è troppo grande. Basta schiaffeggiare la tua riga di codice e fare una doccia veloce.

Regola empirica: pensa sempre a te stesso: " Credo che il business tragga maggiori benefici da questo lavoro tecnico che ritengo di dover fare rispetto al lavoro che mi hanno chiesto quale sarà ritardato di conseguenza? "

Il vantaggio dei test unitari in senso TDD è ottenere qualcosa che si regge da solo, senza la necessità di una tradizione orale costruita negli anni da un team stabile.

È una grande fortuna che lo stesso team faccia parte dello stesso progetto da così tanto tempo. Ma questo alla fine cambierà. Le persone si ammalano, annoiano o promosse. Si muovono, vanno in pensione o muoiono. I nuovi arrivano con nuove idee e l'impulso di riformattare tutto come hanno imparato a scuola. Le aziende vengono vendute e acquistate. Le politiche di gestione cambiano.

Se vuoi che il tuo progetto sopravviva, devi prepararlo per le modifiche.

La scrittura di test unitari rende il codice a prova di futuro. Se la base di codice non ha test, allora dovresti aggiungere nuovi test per tutte le nuove funzionalità perché rende quel pezzo di codice solo un po 'più robusto.

Trovo che l'aggiunta di test, anche nel codice legacy, sia vantaggiosa nel medio-lungo periodo. Se la tua azienda non si preoccupa del medio-lungo termine, cercherei un'altra società. Inoltre, non credo che il test manuale richieda più tempo di quello necessario per scrivere un test unitario impostato. In tal caso, è necessario esercitarsi nel codice kata incentrato sulla scrittura di test.

Certamente le migliori pratiche impongono di testare l'unità di qualsiasi codice modificato. La codifica nel mondo reale comporta tuttavia molti compromessi, tempo e materiali sono limitati.

Quello che devi fare è valutare il costo in termini reali di risoluzione dei bug e di apportare modifiche senza unit test. È quindi possibile valutare l'investimento nella creazione di tali test. I test unitari riducono notevolmente il costo dei lavori futuri, ma ora hanno un prezzo.

In conclusione, se il sistema viene modificato raramente, potrebbe non valere la pena scrivere unit test, ma se è soggetto a modifiche regolari, ne varrà la pena.

Tutte queste piccole decisioni razionali per non creare test stanno accumulando un debito tecnico paralizzante che tornerà a perseguitarti quando qualcuno se ne andrà e un nuovo assunto dovrà entrare e accelerare.

Sì, potrebbe essere costato altre 2-3 ore per scrivere i test unitari, ma se il codice viene rispedito dai test, dovrai testare di nuovo manualmente tutto e documentare di nuovo i tuoi test - non lo fai? Altrimenti come fa a sapere cosa hai testato e quali valori hai usato?

I test unitari documentano il comportamento previsto del codice utilizzato dai dati del test per verificarne la funzionalità e danno ai nuovi programmatori la ragionevole sicurezza di non aver rotto qualcosa durante le modifiche.

Oggi costa un paio d'ore in più rispetto ai test manuali, ma poi si esegue il test ogni volta che si apportano modifiche per risparmiare ore durante la durata del codice.

Tuttavia, se sai che il codice verrà ritirato tra un paio d'anni, tutto ciò che ho detto cambia perché non finirai di inserire i test nel codice e non rimborserà mai.

Il valore dei test unitari non sta solo nel testare una nuova funzionalità quando questa viene sviluppata. Il vantaggio dei test unitari si ottiene principalmente in futuro.

Sì, potrebbe essere necessario spendere quello che sembra come una quantità eccessiva di tempo per rendere il codice legacy verificabile.

Ma se non lo fai, dovresti, o sicuramente dovresti , passare molte, molte, molte più ore a testare la funzione. Non solo sul suo sviluppo iniziale, ma con ogni nuova versione del tuo software. Senza test unitari e altre forme di test automatizzati, non si ha altra opzione se non quella di trascorrere molte ore di test manuali per assicurarsi che la funzionalità non sia stata inavvertitamente interrotta, anche quando tale funzionalità stessa non è stata modificata.