Lavoro in una grande azienda, ma in un team di soli due uomini che sviluppa applicazioni desktop LOB. Ho studiato TDD per un po 'di tempo ormai, e anche se è facile realizzare i suoi benefici per applicazioni più grandi, sto facendo fatica a cercare di giustificare il tempo per iniziare a usare TDD sulla scala delle nostre applicazioni.

Comprendo i suoi vantaggi nell'automazione dei test, nel miglioramento della manutenibilità, ecc., Ma sulla nostra scala, scrivere anche test unitari di base per tutti i nostri componenti potrebbe facilmente raddoppiare i tempi di sviluppo. Dato che siamo già scartati con scadenze estreme, non sono sicuro di quale direzione prendere. Mentre altre pratiche come lo sviluppo iterativo agile rendono perfette da allora, sono un po 'dilaniato dai compromessi di produttività del TDD in una piccola squadra.

I vantaggi di TDD valgono il tempo di sviluppo aggiuntivo per piccoli team con programmi molto stretti?

La brutta verità è che inizialmente ti rallenterà . Ogni nuovo processo o pratica richiede del tempo per accelerare. Nella mia esperienza TDD non paga con l'implementazione iniziale tanto quanto con la manutenzione, la correzione degli errori e l'estensione. So per altri che c'è un pagamento immediato, quindi dipenderà dallo stile di codifica attuale di ogni persona.

Mentre sono un grande sostenitore del TDD (l'ho portato nel mio attuale lavoro) penso che tu abbia bisogno di avere un po 'di respiro (scadenze / scadenze) per esplorare e comprendere la pratica.

Più piccola è la tua squadra, più immediatamente puoi beneficiare del TDD. Ho visto questo pagamento nella dimensione della squadra da 6 a 3.

Il tempo di sviluppo aggiuntivo di cui stai parlando può essere un'illusione .

Ciò che rende TDD diverso dai test unitari standard è che non viene utilizzato solo per eseguire test.

TDD is a new way of developing software. È uno dei modi migliori che conosco.

Pertanto, non è correlato alle dimensioni del progetto. Estrai i vantaggi dalla prima riga di codice .

• ti costringerà a strutturare il tuo codice in un modo che sarà più facile da mantenere e riutilizzare. Guida la progettazione del tuo software.
• renderà il refactoring veloce, sicuro e divertente.
• ti aiuta a scrivere piccoli pezzi di funzionalità che rendono molto più semplice l'implementazione delle attività.
• di solito rende l'attività di debug meno frequente.

malinteso comune, lasciami gridare:

LE PROVE IN TDD SONO PER CARATTERISTICHE

EOM.

Modifica: fammi elaborare: "scrivere ... unit test per tutti o i nostri componenti" è un unit test , non TDD. Uso regolarmente TDD su team one-man con grande successo; il payoff è straordinario.

C'è un grande libro su TDD, The art of unit testing ( sito ufficiale ) che ha i suoi esempi in .net con una versione java sulle opere. La parte buona è che ci sono interi capitoli che prendono in considerazione questioni come "Integrazione dei test unitari nell'organizzazione" - Capitolo 8 e "Lavorare con il codice legacy" - Capitolo 9. Anche se non sono un esperto in questo campo (ancora :-)) , in base alla mia esperienza, credo che questo sia un buon punto di partenza.

Esistono un paio di domande per ottenere le risposte a:

1. Quanto tempo dedichi dopo il rilascio del bug di correzione nel codice? Se riesci a quantificarlo, potresti scoprire che è uguale o addirittura superiore al tempo "extra" che ti richiederebbe per scrivere il test che aiuterebbe a prevenire questi bug.

2. Con quale frequenza una modifica apparentemente semplice per il refactoring del codice o l'aggiunta di nuove funzionalità ha rotto qualcosa apparentemente non correlato? Anche in questo caso con una buona copertura dei test questi possono essere ridotti.

Anche se non riesci a mettere numeri esatti su questi, dovresti essere in grado di dimostrare che stai spendendo questo tempo comunque, quindi potresti anche spenderlo "in anticipo" e (si spera) finire con un prodotto molto più stabile.

Quando le persone mi parlano di iniziare ad adottare i test nel loro team, per prima cosa controllo sempre come verranno eseguiti i test. Spesso i team non hanno una build continua in atto. Se hai risorse limitate, suggerirei che la configurazione di un server CI è un prerequisito per l'avvio di qualsiasi incursione seria nei test.

Una volta ottenuta quella configurazione, inizia a praticare TDD. Tieni presente che se il sistema non è stato sviluppato pensando ai test, potresti avere difficoltà a rendere testabile il codice esistente e sarà costoso ristrutturarlo.

Inizia cercando luoghi facili da cui iniziare con TDD: nuove classi o moduli, con poche dipendenze. Classi di utilità e strutture di dati sono spesso buone cose per cominciare.

Scopri come cambia il modo in cui pensi al tuo codice, nota quanto è meglio il codice che produci e quanto più hai fiducia in quel codice.

So di non aver veramente risposto alla domanda, ma suppongo che il mio punto sia che dovresti essere in grado di fare tutto questo senza un costo aggiuntivo enorme. Lavorando con i tuoi primi esempi capirai meglio i vantaggi del tuo progetto.

In conclusione: sviluppo più lento, ma pochi difetti, molto meno tempo per correggere i bug.

Ecco dove penso che lo sviluppo guidato dal comportamento mostri vantaggi immediati, ma non sono sicuro che lo sviluppo guidato dai test lo faccia.

Nello sviluppo orientato al comportamento ti avvicini ai tuoi biglietti in un modo diverso: ti siedi con l'uomo d'affari e lavori con loro per definire i comportamenti che dovrebbe avere questo pezzo di funzionalità. Lo descrivo in una voce sul mio blog (il titolo del post: Writing Behaviors ).

Sedersi con l'uomo d'affari o chiunque aiuterà te e loro a capire meglio cosa deve fare il sistema affinché tutti siano soddisfatti di quella funzionalità. Cosa deve fare per essere accettato dal processo di controllo qualità che hai in atto.

Definire i criteri di test, quindi scrivere quei criteri di test nella tua suite di test automatizzata, dovrebbe ridurre la quantità di avanti e indietro che ottieni: qualcuno che afferma che la funzionalità è rotta, perché hai perso qualcosa (o perché hai perso legittimamente qualcosa o perché non l'hanno mai detto a riguardo).

Può anche aiutare la percezione altrui della tua squadra: se ti siedi e definisci ciò che deve essere fatto nel sistema, potresti passare da "idioti che ingegnano troppo tutto e trascorrono del tempo su cose che non abbiamo chiesto", a, "gente intelligente che sta arrivando con funzioni utili".

TL; DR: Lo sviluppo guidato dal comportamento può mostrare rapidamente miglioramenti perché è incentrato sul "cliente". Test Driven Development, per me, sembra riguardare test interni della base di codice di cui "nessuno" si preoccupa e offre vantaggi aziendali meno evidenti. (Behavior Driven Development ha l'immediato, in faccia, un cambiamento: gli ingegneri hanno improvvisamente molto più tempo a disposizione con il "cliente" o l'analista aziendale per cercare di ottenere ciò giusto - il che dovrebbe essere visto come una cosa positiva. "Oh , stanno avendo un incontro sulla caratteristica X, il che significa che ci sono progressi su questo fronte! ")