Il test dell'unità aumenta la produttività? [duplicare]

Ho trovato test unitari per aiutare la mia produttività:

1. Mi aiutano a capire come vorrei organizzare il mio codice (classi, metodi, ecc.).
2. Aiutano a documentare come interfacciarsi con il codice.
3. Guardare una unità isolata aiuta a concentrarsi sui casi limite e sulle supposizioni nascoste che potrebbero mordere in seguito.
4. I blocchi di codice che vengono riutilizzati avranno già dei test scritti.
5. Sia il refactoring che il bug fixing possono essere eseguiti in modo più efficiente, dal momento che puoi testare immediatamente se hai rotto qualcos'altro.

Se i tuoi programmi sono effettivamente su una tempistica così breve, e non vengono mai aggiornati (anche per correzioni di bug?), allora potrebbe avere senso trovare il giusto equilibrio tra il test unitario completo che useresti per una libreria del sistema operativo e la manciata rapida e sporca di test manuali che useresti per un programma monouso.

Un paio di suggerimenti extra: in primo luogo, la tua produttività con TDD e i test di unità miglioreranno con la pratica. In secondo luogo, apprendi e utilizza le funzionalità disponibili del tuo ambiente di sviluppo e componenti aggiuntivi che accelerano lo sviluppo dei test unitari.

Trovo che TDD sia utilizzato anche nella programmazione "casuale":

• Ti costringe a pensare a come utilizzerai il codice. Ci sono state alcune volte in cui mi è stato dato un oggetto che qualcun altro ha appena codificato, o addirittura mi sono codificato fuori dal contesto, che si è rivelato un incubo da integrare con il codice esistente perché un intero livello aggiuntivo di astrazione, concrezione e / o l'adattamento generale è necessario. In TDD, l'utilizzo, e quindi un suggerimento dell'integrazione richiesta, è la prima cosa a cui pensi.

• Tende a portare a disegni più incapsulati che sono facili da "inserire". I test unitari sono, per la loro stessa natura, test eseguiti isolatamente, e in genere si desidera che i test siano semplici in modo da poterli eseguire e trovare rapidamente il problema in caso di problemi. La creazione di un oggetto che è facilmente testato in isolamento, quindi, generalmente genera un'interfaccia "esterna" molto semplice e accoppiata liberamente che aiuta a rendere il tuo codice modulare e facile da usare.

• Solo i progetti più semplici possono essere testati a mano in modo completo. I test unitari richiedono un maggiore sviluppo in anticipo, ma riducono la quantità di test da eseguire ogni volta che viene aggiunta una nuova funzionalità. Eseguendo i tuoi test unitari, proverai che non solo ciò che stai scrivendo si comporta come previsto, ma che ciò che hai costruito con STILL funziona come previsto anche dopo averlo fatto fuori per aggiungere nuove cose.

• Incoraggia la progettazione guidata dal comportamento. Scrivi una suite di test sapendo cosa dovrà fare l'oggetto sotto test. Ciò scoraggia "l'ottimizzazione prematura" e incoraggia l'adesione a YAGNI.

Una cosa che i test unitari sicuramente ottengono per me, è aumentare la mia fiducia. Mi sento sicuro di modificare, riscrivere o refactoring il codice esistente, con la certezza che se avessi fatto qualcosa di sbagliato, i test falliranno. In caso contrario, so che le mie modifiche erano corrette. In un certo senso è una conferma per il comportamento del codice.

(Naturalmente tutto ciò presuppone che i test unitari siano corretti e approfonditi, ma richiede tempo, ma a lungo termine si paga)

Penso che dipenda dal tipo di progetto su cui stai lavorando.

Ho avuto un'esperienza in cui abbiamo scritto una serie di test unitari su un progetto senza un chiaro modello di dominio. Quando il modello di dominio è stato refactored, molti test unitari sono diventati irrilevanti e hanno dovuto essere riscritti. Con la terza iterazione ci siamo arresi, non li avevamo mai usati e dovevano essere riscritti ancora una volta.