Ci sono aree in cui TDD fornisce un ROI elevato e altre aree in cui il ROI è così basso che non vale la pena seguirlo? [chiuso]

Sviluppo guidato da test. Ho capito, mi piace.

Ma scrivere test richiede un sovraccarico. Quindi, il TDD dovrebbe essere usato universalmente in tutta la base di codice o ci sono aree in cui TDD fornisce un ROI elevato e altre aree in cui il ROI è così basso che non vale la pena seguirlo.

Direi di evitare TDD in luoghi in cui è probabile che il codice cambi molto strutturalmente. Vale a dire, è bello avere una pila di test per un metodo la cui firma cambia raramente ma viene refactoring internamente più frequentemente, ma fa schifo dover correggere i test ogni volta che un'interfaccia altamente volatile cambia in modo drammatico.

Le app su cui ho lavorato di recente sono state webapp basate sui dati basate su un'architettura basata su Gui-> Presenter-> BusinessLogic-> Data Access Layer. Il mio livello di accesso ai dati è testato come nessun altro. Il livello di logica aziendale è piuttosto ben testato. I presentatori vengono testati solo nelle aree più stabili e la GUI, che cambia ogni ora, non ha quasi alcun test.

Suggerisco di scrivere una suite di test completa nelle aree in cui è ragionevole e pratico da fare. In aree meno pratiche, scrivere controlli di integrità.

Nella mia esperienza, l'overhead di una serie completa di casi di test è sicuramente valsa la pena nella maggior parte dei casi, ma realisticamente la copertura del codice ha rendimenti decrescenti. Ad un certo punto, scrivere più test solo per aumentare la copertura del codice non ha senso.

Ad esempio, a seconda della lingua / della tecnologia, testare l'interfaccia utente potrebbe non essere pratico o addirittura fattibile. Molti test si baseranno probabilmente su ciò che un utente vede e non possono essere automatizzati. Come testeresti che un metodo per generare un captcha produce ad esempio un'immagine leggibile da un essere umano?

Se ci vorranno tre giorni per scrivere un set completo di test, la probabilità che un bug venga introdotto in quel componente lungo la traccia è molto bassa e la stessa funzione richiede solo mezz'ora per scrivere, probabilmente dovresti pensare molto sul fatto che quel tempo valga la pena. Forse solo scrivere un controllo di integrità di base per quella funzione fornirebbe valore?

Il mio consiglio generale è che dovresti testare completamente i componenti dove i test possono essere scritti relativamente facilmente. Tuttavia, se si tratta di un'area che è molto difficile da testare, tracciare una linea nella sabbia e scrivere test che testeranno l'area a un livello superiore anziché testarla completamente.

Nel precedente esempio captcha, forse scrivere test che controllano che venga restituita un'immagine della dimensione e del formato corretti e che non vengano generate eccezioni. Questo ti dà un certo livello di sicurezza senza esagerare.

Per me, TDD non è sovraccarico. È solo il modo in cui scrivo il codice. Perché dici che scrivere test è "sovraccarico"? È solo una parte del processo. Il mio punto di vista è che il debug è sovraccarico, e questa è un'attività che essenzialmente ho smesso di fare quando ho iniziato TDD-ing. Prima di TDD, il debug era parte integrante del mio processo di scrittura del software.

Penso che rinunciare al debug per la scrittura di test sia un ottimo affare.

Un punto in cui TDD fa davvero schifo è quando si testano le viste in un'app MVC.

Dal momento che stai testando una funzione che restituisce una grossa stringa HTML, sei bloccato a fare l'analisi HTML solo per vedere se le cose hanno funzionato. Inoltre, può diventare un incubo di manutenibilità. Un giorno muovi una casella di controllo e Kaboom, il tuo test viene interrotto.

Mi piace TDD per molti dei miei test, ma non è l'unico strumento in una cintura di programmatori.