Sviluppo guidato dai test. Ho capito, mi piace.
Ma scrivere test richiede un sovraccarico. Quindi il TDD dovrebbe essere utilizzato universalmente in tutto il codice base, oppure ci sono aree in cui TDD fornisce un ROI elevato e altre aree in cui la ROI è talmente bassa da non meritare di essere seguita.
Direi di evitare il TDD in luoghi in cui il codice potrebbe cambiare molto strutturalmente. Vale a dire, è bello avere una pila di test per un metodo la cui firma cambia raramente ma viene sottoposta a refactoring internamente più frequentemente, ma fa schifo dover aggiustare i test ogni volta che un'interfaccia altamente volatile cambia drasticamente.
Le app su cui ho lavorato di recente sono state webapp basate sui dati e basate su un'architettura basata su Gui > Presenter- > BusinessLogic- > Data Access Layer. Il mio livello di accesso ai dati è testato come se fossero affari di nessuno. Il livello della logica aziendale è abbastanza ben collaudato. I presentatori vengono testati solo nelle aree più stabili e la GUI, che sta cambiando ogni ora, non ha quasi alcun test.
Suggerisco di scrivere una suite completa di test in aree in cui è ragionevole e pratico da fare. In aree meno pratiche, scrivi controlli di integrità.
Nella mia esperienza, il sovraccarico di una serie completa di casi di test vale sicuramente 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 / 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 può essere automatizzato. Come testesti che un metodo per generare un captcha produce un'immagine che è leggibile da un essere umano, per esempio?
Se un set completo di test ti richiederà tre giorni per scrivere, la probabilità che un bug venga introdotto in quel componente lungo la traccia è molto bassa, e la funzione stessa richiede solo mezz'ora per scrivere, dovresti probabilmente pensa seriamente se valga la pena. Magari solo scrivere un controllo di base per la funzionalità di tale funzione fornirebbe un valore?
Il mio consiglio generale è che dovresti testare completamente i componenti dove i test possono essere scritti in modo relativamente facile. Tuttavia, se si tratta di un'area che è molto difficile da testare, traccia una linea nella sabbia e scrivi test che testeranno l'area a un livello più alto anziché testarlo completamente.
Nell'esempio captcha precedente, è possibile scrivere test che controllano un'immagine della dimensione e del formato corretti e che non vengono emesse eccezioni. Questo ti dà un certo livello di sicurezza senza esagerare.
Per me, TDD non è un sovraccarico. È solo il modo in cui scrivo il codice. Perché dici che il test di scrittura è "overhead"? È solo una parte del processo. Il mio punto di vista è che il debug è un overhead, e questa è un'attività che sostanzialmente smisi di fare quando ho avviato TDD-ing. Prima di TDD, il debugging era parte integrante del mio processo di scrittura del software.
Penso che rinunciare al debugging per i test-writing sia un ottimo affare.
Un luogo in cui TDD fa veramente schifo è quando si testano le viste in un'app MVC.
Dato che stai testando una funzione che restituisce una stringa html grassa, sei bloccato mentre esegui l'analisi html solo per vedere se la roba ha funzionato. Inoltre, può diventare un incubo di manutenibilità. Un giorno si sposta una casella di controllo e kaboom, il test è rotto.
Mi piacciono i TDD per molti dei miei test, ma non è l'unico strumento in una cintura di programmatori.
Leggi altre domande sui tag tdd development-process