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

Devi essere pragmatico riguardo a queste situazioni. Tutto deve avere un valore aziendale, ma l'azienda deve fidarsi di te per giudicare qual è il valore del lavoro tecnico. Sì, c'è sempre un vantaggio nell'avere dei test unitari, ma è un beneficio abbastanza grande da giustificare il tempo trascorso?

Vorrei discutere sempre sul nuovo codice ma, su un codice legacy, devi fare un giudizio.

Sei spesso in quest'area di codice? Poi c'è un caso per il miglioramento continuo. Stai facendo un cambiamento significativo? Poi c'è un caso che è già un nuovo codice. Ma se stai realizzando un codice a una riga in un'area complessa che probabilmente non verrà più toccata per un anno, ovviamente il costo (per non parlare del rischio) di reingegnerizzazione è troppo grande. Basta schiaffeggiare la tua riga di codice e andare a fare una doccia veloce.

Regola empirica: pensa sempre a te stesso, " Credo che gli affari traggano beneficio più da questo lavoro tecnico che sento che dovrei fare piuttosto che dal lavoro che hanno chiesto e che di conseguenza sarà ritardato? "

Il guadagno dei test unitari in senso TDD è quello di ottenere qualcosa che si regge da solo, senza bisogno di una tradizione orale costruita negli anni da una squadra stabile.

È una grande fortuna che lo stesso team sia stato sullo stesso progetto per così tanto tempo. Ma questo alla fine cambierà. Le persone si ammalano, si annoiano o promuovono. Si muovono, si ritirano o muoiono. I nuovi arrivano con nuove idee e l'impulso di rifattorizzare tutto nel modo in cui 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.

Scrittura di unit test è la prova del codice futuro. Se il code base non ha test, allora dovresti aggiungere nuovi test per tutte le nuove funzionalità perché rende quel bit del codice solo un po 'di più robusto.

Trovo che l'aggiunta di test, anche nel codice precedente, sia utile nel medio-lungo periodo. Se alla tua azienda non interessa il medio-lungo termine, cercherò un'altra azienda. Inoltre, non penso che ci voglia più tempo per testare manualmente di quanto ci vuole per scrivere un test unitario. Se lo fa, allora hai bisogno di praticare il codice Kata focalizzato sulla scrittura dei test.

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

Quello che devi fare è valutare il costo in termini reali di correggere bug e apportare modifiche senza test unitari. È quindi possibile valutare contro l'investimento nella creazione di tali test. I test unitari riducono notevolmente il costo del lavoro futuro, ma ora hanno un prezzo.

La linea di fondo è che se il tuo sistema viene cambiato raramente allora potrebbe non valere la pena di scrivere test unitari, ma se è soggetto a cambiamenti regolari, ne varrà la pena.

Tutte queste piccole decisioni razionali per non creare test stanno creando un debito tecnico paralizzante che tornerà a perseguitarti quando qualcuno lascerà & una nuova assunzione deve venire in & mettiti al passo.

Sì, potrebbero essere necessarie altre 2-3 ore per scrivere i test unitari, ma se il codice viene restituito dai test, dovrai testare di nuovo tutto di nuovo e documentare i test, ancora una volta - fai quel don ' tu? Altrimenti come fa qualcuno a sapere cosa hai testato e quali valori hai usato?

I test unitari documentano il comportamento previsto del codice, i dati del test utilizzati per verificare la funzionalità e danno ai nuovi programmatori la ragionevole certezza che non abbiano rotto qualcosa durante le modifiche.

Oggi costa più di un paio di ore rispetto ai test manuali, ma poi esegui dei test ogni volta che modifichi le ore di salvataggio per tutta la durata del codice.

Tuttavia, se sai che il codice verrà ritirato in un paio di anni, non ho detto tutte le modifiche perché non terminerai di mettere i test nel codice & non ripagherà mai.

Il valore dei test unitari non si limita a testare una nuova funzione quando viene sviluppata. Il vantaggio dei test unitari si ottiene principalmente in futuro.

Sì, potresti dover spendere ciò che sembra come una quantità eccessiva di tempo per rendere testabile il tuo codice legacy.

Ma se non lo fai, lo farai, o certamente dovrebbe , spendere molte, molte, molte più ore a testare la funzionalità. Non solo nel suo sviluppo iniziale, ma con ogni nuova versione del tuo software. Senza test unitari tu e altre forme di test automatizzati, non hai altra scelta che passare molte ore di test manuali per assicurarti che la tua funzione non sia stata inavvertitamente interrotta, anche quando quella funzionalità non è stata modificata.