Alla ricerca di case study su come il TDD ha migliorato la qualità e / o la velocità di sviluppo [chiuso]

Nella mia azienda sto cercando di spiegare il motivo per cui dovremmo fare TDD. Attualmente la maggior parte degli sviluppatori fa semplicemente tutto il possibile per portare a termine il progetto, quindi aggiunge test unitari dopo il fatto per soddisfare le metriche del gestore. Eventuali esempi di aziende rispettabili che fanno TDD e vedono i benefici sarebbero molto apprezzati.

Uno studio di 4 progetti in IBM e Microsoft. Pubblicato in Emperical Software Engineering rivista .

Studi empirici dimostrano che lo sviluppo guidato dai test migliora la qualità

Un articolo pubblicato per la prima volta sulla rivista Empirical Software Engineering riporta: "Il TDD sembra essere applicabile in vari settori e può ridurre significativamente la densità di difetto del software sviluppato senza una significativa riduzione della produttività del team di sviluppo". Lo studio ha confrontato 4 progetti, presso Microsoft e IBM che hanno utilizzato TDD con progetti simili che non hanno utilizzato TDD ...

L'articolo include 1 caso di studio presso IBM e 3 da Microsoft. Ciascuno dei casi di studio confronta due team che lavorano sullo stesso prodotto, utilizzando gli stessi linguaggi e tecnologie di sviluppo, sotto lo stesso manager di livello superiore, solo uno dei quali utilizzava lo sviluppo guidato dai test (TDD). Nessuno dei team sapeva che sarebbero stati parte dello studio durante i loro cicli di sviluppo. Il case study IBM ha seguito i team che si occupavano dello sviluppo del driver di dispositivo. I casi Microsoft hanno seguito i team che lavorano su Windows, MSN e Visual Studio.

Il documento descrive le pratiche TDD utilizzate dai team come flussi di lavoro minuto per minuto, nonché flussi di lavoro a livello di attività ...

C'è un capitolo sul TDD con un case study nel recente libro "Making Software: cosa funziona e perché ci crediamo". Ma potresti essere deluso, poiché se ricordo bene lo studio non ha rivelato alcun reale beneficio per il TDD. Il case study è stato comunque interessante e il libro in generale è uno dei migliori libri sul software che ho letto di recente. Contiene molti casi studio di cose come la programmazione di coppie, la revisione del codice, ecc.

Dai un'occhiata a questo: TDD dimostrato efficace! O è?

... quando Phil Haack annunciò che la ricerca supporta l'efficacia del TDD ero più che un po 'interessato a vedere cosa conteneva il rapporto collegato . Phil cita dall'estratto.

Abbiamo scoperto che gli studenti che hanno iniziato il test in media hanno scritto più test e, a loro volta, gli studenti che hanno scritto più test tendevano ad essere più produttivi. Abbiamo anche osservato che la qualità minima è aumentata linearmente con il numero di test del programmatore, indipendentemente dalla strategia di sviluppo utilizzata.

Phil ha ovviamente letto il resto del rapporto e fornisce i suoi pezzi preferiti che sembrano fare come suggerisce il titolo. Una delle cose di cui mi preoccupo quando vedo cose che supportano le più recenti e grandi pratiche di sviluppo software, tuttavia, è una forte tendenza al bias di conferma - di cercare la conferma delle teorie attuali e trascurare i contro-indicatori.

Quindi, essendo il tipo curioso e dato che TDD è qualcosa su cui sto tenendo d'occhio per vedere se è qualcosa che potrei voler adottare un giorno, sono entrato nel rapporto ...

... senza dubbio, test prima porta ad avere più test per unità funzionale. La domanda è se questo è prezioso. Questo studio sembrerebbe indicare che probabilmente non è così, almeno se la qualità è il guadagno previsto. Ma poi, non sono così sorpreso che il numero di test non corrisponda alla qualità così come non sono sorpreso 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 (imo nonostante sia stato pubblicizzato a morte)

guarda quanto tempo tu e il cliente avete trascorso test manuali del software; confrontarlo con una stima di quanto tempo sarebbero stati necessari i test automatici in stile TDD. Tasca la differenza

nella mia esperienza, i test automatizzati di TDD sono d'oro perché forniscono assicurazione ed eliminano enormi quantità di test manuali

come ha sottolineato Andres F, puoi ottenere questi benefici semplicemente dai test automatici, non necessariamente TDD - tuttavia, TDD richiede test automatizzati invece di essere un ripensamento o piacevole da avere

Essere costretti a pensare prima ai test ti costringe anche a pensare a problemi relativi alla qualità - come la modularità, la progettazione dell'interfaccia e così via - prima di iniziare a scrivere codice.

Personalmente, credo che uno dei maggiori vantaggi di TDD sia che la scrittura del test mantiene innanzitutto la specifica di ciò che il codice deve effettivamente fare nella tua mente mentre stai scrivendo il codice, piuttosto che una sorta di immaginazione -come-you-code.

vuoi fare il caso per esso: suggerisci di farlo per il prossimo progetto, e poi impara da esso. Se si scopre che funziona benissimo per te, spero che continuerai a usarlo e se impiegherai più tempo a fare il progetto e / o passerai tutto il tuo tempo a scrivere test invece di scrivere codice, allora sicuramente lo scaricherai come un fallimento.

Penso che la soluzione del mondo reale sia (come la maggior parte delle cose) una via di mezzo, vuoi dei test ma non vuoi che i test siano più importanti del progetto.

(personalmente penso che TDD sia una mania, suona bene in teoria, ma in pratica ... non così bene. Trovo che i test di integrazione siano molto più importanti, ma potrebbe essere proprio il tipo di progetti complessi su cui lavoro).

Ho lavorato con TDD per 2 anni e dove lavoravo all'epoca, eravamo tutti riluttanti a usare i manager inclusi, ma presto si è rivelato essere la cosa giusta da fare. I vantaggi che abbiamo notato presto erano

• Alla scoperta di bug in una fase iniziale.
• Scrivere codice migliore senza nemmeno rendersene conto.
• Il tuo codice è ora più gestibile in quanto a causa del tuo test è tutto in piccoli pezzi (avevamo funzioni che erano 300-400 linee) sciocco. Ora max 30 e tutti testati in modo indipendente.

I gestori non saprebbero perché sono tutti interessati a una cosa "Hai finito". Ma poi si lamentano quando il software continua a rompersi senza accorgersene. Con una buona copertura e test sensati. Non è la quantità ma la qualità che puoi davvero vedere quando qualcuno rompe una funzionalità. Inoltre, purtroppo è difficile se sei da solo, ho avuto lo stesso problema, in quanto potresti aver bisogno di cambiare codice, ad esempio classi di base, ecc. In modo da poter testare parti del software.

Ti faccio un esempio. Volevo deridere il repository ma non c'era interfaccia e ho bisogno di iniettare il repository nel mio livello di servizio e quindi aggiungere / modificare un costruttore in tutto il negozio, questo si è rivelato un grosso problema ma in Alla fine ho più di 200 test solo testando un'area del sistema e sono rimasti colpiti.

Di solito faccio quanto segue:

• Tengo i miei unittest molto brevi
• Solo 1 affermazione. Nessuna roulette russa.
• Ho testato uno scenario positivo-negativo ed eccezionale

Per quanto riguarda i casi di studio, temo di non averne visto nessuno. Devi costruire il tuo progetto e diventare il tuo caso di studio, ma potrebbero anche essere colpiti.

spero possa essere d'aiuto