Nella mia azienda sto cercando di spiegare perché dovremmo fare TDD. Attualmente la maggior parte degli sviluppatori fa tutto il possibile per portare a termine il progetto, quindi aggiunge i test unitari dopo il fatto per soddisfare le metriche del gestore. Qualsiasi esempio di aziende affidabili che fanno TDD e vedendo i benefici sarebbe molto apprezzato.
Uno studio su 4 progetti in IBM e Microsoft. Pubblicato in rivista di Ingegneria del software empirica .
Studi empirici mostrano lo sviluppo guidato dai test Migliora la qualità
A paper first published in the Empirical Software Engineering journal reports: "TDD seems to be applicable in various domains and can significantly reduce the defect density of developed software without significant productivity reduction of the development team." The study compared 4 projects, at Microsoft and IBM that used TDD with similar projects that did not use TDD...
The paper includes 1 case study at IBM and 3 from Microsoft. Each of the case studies compare two teams working on the same product, using the same development languages and technologies, under the same higher-level manager, only one of which was using test-driven development (TDD). None of the teams knew that they would be part of the study during their development cycles. The IBM case study followed teams doing device driver development. The Microsoft cases followed teams working on Windows, MSN, and Visual Studio.
The paper describes the TDD practices used by the teams as minute-to-minute workflows, as well as task-level workflows...
C'è un capitolo sul TDD con un case study nel recente libro "Making Software: What works and why we believe". Ma potresti rimanere deluso, dal momento che, se ricordo bene, lo studio non ha rivelato alcun beneficio reale per TDD. Il case study è stato comunque interessante e il libro in generale è uno dei migliori libri di software che ho letto di recente. Contiene molti casi di studio su cose come la paia di programmazione, la revisione del codice, ecc.
Dai un'occhiata a questo: TDD Proven Efficace! O è?
...when Phil Haack announced that Research Supports the Effectiveness of TDD I was more than a little interested in seeing what the linked report actually contained. Phil quotes from the abstract.
We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive. We also observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed.
Phil ha ovviamente letto il resto del rapporto e fornisce i suoi pezzi preferiti che sembrano fare come suggerisce il suo titolo. Una delle cose di cui mi preoccupo quando vedo cose che supportano le ultime e più grandi pratiche di sviluppo del software, tuttavia, è una strong tendenza verso bias di conferma - di cercare la conferma delle teorie correnti e trascurare i contro-indicatori.
Quindi, essendo il tipo curioso e dal momento che TDD è qualcosa che sto tenendo d'occhio per vedere se è qualcosa che potrei voler adottare un giorno, sono entrato nel report ...
... senza dubbio, il primo test porta ad avere più test per unità funzionale. La domanda è se questo è prezioso. Questo studio sembrerebbe indicare che questo non è probabilmente il caso, almeno se la qualità è il tuo scopo di guadagno. Ma poi, non sono così sorpreso che il numero di test non corrisponda alla qualità proprio come non mi sorprende che il numero di righe di codice non corrisponda alla produttività.
L'autore ha molti punti positivi sul fatto che TDD non sia così efficace (nonostante sia stato pubblicizzato a morte)
guarda quanto tempo hai e il client passato a testare manualmente il software; confrontarlo con una stima di quanto tempo avrebbero impiegato i test automatici in stile TDD. Trova la differenza
nella mia esperienza, i test automatici di TDD sono gold perché forniscono insurance ed eliminano enormi quantità di test manuali
come ha sottolineato Andres F, è possibile ottenere questi benefici semplicemente dai test automatici, non necessariamente TDD - tuttavia, TDD richiede test automatici invece di essere un ripensamento o bello da avere p>
Essere costretti a pensare prima ai test ti costringe anche a pensare a questioni relative alla qualità, come modularità, design dell'interfaccia e così via, prima di iniziare a scrivere codice.
Personalmente, ritengo che uno dei maggiori vantaggi del TDD sia che scrivere il test prima mantiene le specifiche di ciò che il codice deve effettivamente fare nella tua mente mentre scrivi il codice, piuttosto che il tipo di rappresentazione it-out-as-you-codice.
vuoi spiegarlo: suggerisci di farlo per il prossimo progetto e poi di imparare da esso. Se si scopre che funziona benissimo per te, allora spero che continuerai a usarlo e se ci vorrà più tempo per fare il progetto e / o passerò tutto il tuo tempo a scrivere test invece di programmare, allora sicuramente lo scaricherai come un fallimento.
Penso che la soluzione del mondo reale sia (come la maggior parte delle cose) a metà strada, vuoi test ma non vuoi che i test siano più importanti del progetto.
(personalmente penso che TDD sia una moda passeggera, suona bene in teoria, ma in pratica ... non è così bello, trovo che i test di integrazione siano molto più importanti, ma potrebbe essere solo il tipo di progetti complessi su cui lavoro) .
Ho lavorato con TDD per 2 anni e, quando lavoravo in quel periodo, eravamo tutti riluttanti a utilizzare i gestori. Tuttavia, presto si è rivelata la cosa giusta da fare. I vantaggi che abbiamo notato presto erano
I dirigenti non saprebbero come sono tutti interessati a una cosa "Hai finito". Ma poi si lamentano quando il software continua a rompersi senza rendersene conto. Con una buona copertura e test sensati. Non è la quantità, ma la qualità che puoi vedere quando qualcuno rompe una funzionalità. Inoltre, sfortunatamente è difficile se sei da solo. Ho avuto lo stesso problema, poiché potresti aver bisogno di cambiare codice, ad es. Classi base ecc. In modo che tu possa rendere testabili alcune parti del software.
Ti do un esempio. Volevo prendere in giro il repository ma non c'era alcuna interfaccia e ho bisogno di iniettare il repository nel mio livello di servizio e quindi aggiungere / modificare un costruttore in tutto il negozio, questo risultò essere un grande affare ma alla fine ho più di 200 test solo testando una zona del sistema e sono rimasti colpiti.
Di solito faccio quanto segue:
Per quanto riguarda gli studi di casi temo, non sono sicuro di averne mai visto. Devi costruire il tuo progetto e diventare il tuo caso studio. Potrebbero essere impressionati.
Spero che aiuti
Leggi altre domande sui tag tdd