Il test unitario è al 100% o non è affatto un affare?
Stavo sfogliando i miei vecchi progetti e ho iniziato ad aggiungere funzionalità, questa volta con test unitari. Tuttavia, questo alla fine è inutile se sto per riutilizzare componenti passati che non hanno test unitari?
Devo scrivere test unitari per tutte le classi precedenti e non preoccuparmi affatto, oppure è giusto scrivere solo unit test per le nuove cose che sto aggiungendo?
Risposte:
Qualsiasi test unitario è migliore di nessuno. Quindi non è un affare tutto o niente.
Nel tuo caso, dal momento che Test Driven Development non è stata la norma, ti chiederai come i test possano essere utili.
Vuoi assicurarti che qualsiasi codice futuro che scrivi non rompa alcuna funzionalità (attuale) - ed è qui che i tuoi sotto-casi tornano utili. Se i test ben scritti superano, molto probabilmente non hai danneggiato nulla. Il prossimo sviluppatore che arriverà ti ringrazierà per i test e la documentazione.
Quello che puoi iniziare è se hai un'architettura a strati ben suddivisa, raccogli i livelli di accesso ai dati e lavori verso l'alto (verso il livello dell'interfaccia utente) con i test. Se il progetto ha un modello di dominio è il candidato più probabile per TDD in quanto ha probabilmente la maggior parte della logica. Se il livello del servizio (o della logica aziendale) sta semplicemente effettuando una chiamata al livello Accesso dominio / dati, non ha senso fare il livello del servizio in modo TDD. Quelli sono test soffici e non di grande valore.
Aggiunto a uno strumento di copertura del codice come Emma - e puoi monitorare costantemente il miglioramento della copertura complessiva del test.
Ho lavorato su una base di codice molto ampia che inizialmente non aveva test unitari. Seguendo alcune pratiche ora (dopo diversi anni) abbiamo la maggior parte della base di codice coperta dai test.
Tutto il nuovo codice deve avere unit test.
A tutto il codice modificato devono essere aggiunti test unitari.
Il modo in cui abbiamo aggiunto in modo sicuro test al vecchio codice senza romperlo è principalmente quello di utilizzare il seguente approccio di base:
Scegli una piccola sezione di codice di cui devi modificare la funzionalità.
Introdurre le interfacce necessarie per poter testare il codice che si sta modificando. Utilizzare le tecniche di refactoring costituite da sequenze di modifiche molto piccole di cui si ha un'elevata sicurezza sono corrette. Prova a utilizzare il supporto degli strumenti, ove possibile. È possibile farlo, ad esempio, spostando / estraendo il metodo che si sta modificando sul proprio oggetto. Controlla regolarmente le modifiche in modo da poter ripristinare. Esamina regolarmente il peer review di come hai apportato le modifiche esaminando la cronologia dei controlli di revisione.
Cerca di apportare il minimo delle modifiche necessarie per interrompere le dipendenze che ti impediscono di aggiungere test.
Abbiamo scoperto che più lo facevamo, più facile diventava. Come ogni volta che torni alla base di codice, è un po 'meglio.
Abbiamo riscontrato un forte calo del numero di bug che arrivano ai nostri tester di controllo qualità. Con le regressioni di funzionalità ormai quasi sconosciute, quindi penso che ne sia valsa la pena.
(per la mancanza di capacità di commentare) Penso che sia meglio che non testare affatto. Non tutti i frammenti devono essere testati, ma solo ciò che verrà eventualmente utilizzato dal programmatore. È utile testare le funzioni di utilità utilizzate internamente, ma non è necessario se successivamente si accede a tutto tramite un'API pulita.
Se la vecchia roba ha funzionato bene per anni, la creazione dei test unitari non è obbligatoria a meno che non si cambi qualcosa nella vecchia roba. Ad ogni modo, scrivere test unitari per le nuove parti non è affatto inutile. Le nuove parti sono quelle che hanno più probabilità di contenere bug e sono anche le parti che hanno maggiori probabilità di essere modificate o refactored.
Puoi iniziare a coprire il tuo codice attuale e, se hai del tempo da dedicare, iniziare a coprire le funzionalità di base del vecchio codice. Inoltre puoi chiedere al tuo PM un po 'di tempo extra per quello =)
Il test unitario è al 100% o non è affatto un affare?
Assolutamente no! Inizia a testare il nuovo codice che stai aggiungendo. Vedrai immensi benefici nel farlo, anche se alcuni dei componenti più vecchi non hanno test. Dato che devi occuparti di uno di questi componenti o trovare un bug, scrivi un test. Nel tempo otterrai più codice precedente sotto test.