Test di unità di scrittura nel mezzo

Qualsiasi test unitario è meglio di niente. Quindi non è un affare tutto o niente.

Nel tuo caso, dal momento che Test Driven Development non è stato la norma, ti chiederai in che modo i test sono utili.

Vuoi assicurarti che qualsiasi codice futuro che scrivi non interrompa alcuna (attuale) funzionalità - ed è qui che i tuoi sottocasi tornano utili. Se superano i test ben scritti, molto probabilmente non hai danneggiato nulla. Il prossimo sviluppatore che verrà vi ringrazierà per i test e la documentazione.

Ciò 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 è probabile che abbia la maggior parte della logica. Se il livello del servizio (o della logica aziendale) sta semplicemente effettuando una chiamata al livello di accesso al dominio / accesso ai dati, non è necessario eseguire il livello di servizio in modalità TDD. Quelli sono test soffici e non di molto 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 grande che inizialmente non aveva test di unità. Seguendo alcune pratiche, ora (dopo diversi anni) la maggior parte della base di codice è coperta dai test.

Tutti i nuovi codici devono avere test delle unità.

A tutti i codici modificati devono essere stati aggiunti test di unità.

Il modo in cui abbiamo tranquillamente aggiunto test al vecchio codice senza interromperlo è principalmente quello di utilizzare il seguente approccio di base:

Scegli una piccola sezione di codice che è necessario modificare la funzionalità di.

1. Prova a creare test di integrazione a livello di sistema per circondare il codice. A causa della complessità combinatoria dei test a questo livello, questi test formeranno solo un test "fumo" per raccogliere gli errori più importanti.

2. Introduci le interfacce necessarie per poter testare il codice che stai modificando. Usa tecniche di Refactoring che consistono in sequenze di cambiamenti molto piccoli che hai alta confidenza sono corrette. Prova a utilizzare il supporto strumenti ove possibile. Puoi farlo, ad esempio, spostando / estraendo il metodo che stai modificando sul proprio oggetto. Controlla regolarmente le modifiche per poterle ripristinare. Registra periodicamente la revisione da parte dell'utente delle modifiche apportate passando attraverso la cronologia del controllo di revisione.

   Cerca di fare il minimo delle modifiche richieste per rompere le dipendenze che ti impediscono di aggiungere test.

3. Scrivere test per quanto possibile coprire la funzionalità del codice che si intende modificare. Effettua il check-in regolarmente e rivedi tutti i cambiamenti.
4. Scrivi test per la nuova funzionalità / cambio di funzionalità.
5. Implementa la funzionalità (questo è il tuo normale ciclo TDD)
6. Assicurati di refactoring le aree che hai coperto dai test (red-green-refactor).

Abbiamo scoperto che più lo facevamo, più facile diventava. Come ogni volta che torni al codice base, è un po 'meglio.

Abbiamo assistito a un massiccio calo del numero di bug che arrivavano ai nostri tester del QA. Con regressioni di funzionalità ormai quasi sconosciute, penso che ne valga la pena.

(per la mancanza di capacità di commentare) Penso che sia meglio non testare affatto. Non tutti i frammenti devono essere testati, ma solo quello che verrà utilizzato dal programmatore. Testare le funzioni di utilizzo che si utilizzano internamente è buono, ma non necessario se si accede a tutto tramite un'API pulita in seguito.

Se la roba vecchia ha funzionato bene per anni, la creazione dei test unitari ora non è obbligatoria a meno che non si cambi qualcosa nelle cose vecchie. Ad ogni modo, scrivere i test unitari per le nuove parti non è affatto inutile. Le nuove parti sono quelle con maggiori probabilità di contenere bug, e sono anche le parti che più probabilmente saranno modificate o refactored.

Puoi iniziare a coprire il tuo codice corrente e, se hai tempo da dedicare, inizia a coprire le funzionalità di base del vecchio codice. Inoltre puoi chiedere al tuo PM un po 'di tempo extra per quello =)

Is unit testing a 100% or not at all kind of deal?

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. Poiché devi gestire uno di questi componenti o trovare un bug, scrivi un test. Con il passare del tempo otterrete più del vecchio codice sotto test.