La brutta verità è che inizialmente ti rallenterà . Ogni nuovo processo o pratica impiega qualche tempo per iniziare. Nella mia esperienza TDD non paga con l'implementazione iniziale tanto quanto con la manutenzione, il bug fixing e l'estensione. So che per gli altri c'è un pagamento immediato, quindi dipenderà dallo stile di codifica corrente di ogni persona.

Anche se sono un grande sostenitore del TDD (l'ho portato al mio attuale lavoro) penso che sia necessario avere un po 'di respiro (scadenze / scadenze) per esplorare e comprendere la pratica.

Quanto più piccola è la tua squadra tanto più immediatamente potrai beneficiare di TDD. Ho visto questo pagamento nella dimensione della squadra da 6 a 3.

Il tempo di sviluppo extra di cui parli potrebbe essere un'illusione .

Ciò che rende TDD diverso dai test unitari standard è che non è solo usato per fare test.

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

Pertanto, non è correlato alla dimensione del tuo 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 piacevole.
• ti aiuta a scrivere blocchi più piccoli di funzionalità che semplificano l'implementazione dei compiti.
• di solito rende l'attività di debug meno frequente.

equivoco comune, lasciatemi gridare:

I TEST IN TDD SONO PER CARATTERISTICHE

EOM.

Modifica: lasciatemi elaborare: "scrivere ... test unitari per tutti o nostri componenti" è test dell'unità , non TDD. Io uso abitualmente TDD su squadre individuali con grande successo; il guadagno è straordinario.

C'è un ottimo libro su TDD, L'arte del test unitario ( sito ufficiale ) che ha i suoi esempi in .net con una versione java sui lavori. La parte buona è che ci sono interi capitoli che considerano questioni come "Integrare i test delle unità 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.

Ci sono un paio di domande di cui hai bisogno per ottenere le risposte:

1. Quanto tempo passi dopo aver risolto bug nel codice? Se riesci a quantificare questo, potresti scoprire che è uguale o addirittura superiore al tempo "extra" che ti richiederebbe di scrivere il test per impedire che questi errori accadano.

2. Quanto spesso una modifica apparentemente diretta per il refactoring del codice o l'aggiunta di una nuova funzione ha rotto qualcosa apparentemente non correlato? Ancora una volta con una buona copertura di prova, questi possono essere ridotti.

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

Quando le persone mi parlano di come 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 disponi di risorse limitate, suggerirei che impostare un server CI sia un prerequisito per l'avvio di eventuali gravi incursioni nei test.

Una volta che hai questa configurazione, inizia a praticare TDD. Tieni a mente che se il sistema non è stato sviluppato pensando ai test, potresti sforzarti di rendere testabile il codice esistente, e sarà costoso ristrutturarlo.

Inizia cercando posti facili da iniziare con TDD: nuove classi o moduli, con poche dipendenze. Le classi di utilità e le strutture dati sono spesso ottime cose per cominciare.

Scopri come cambia il modo in cui pensi al tuo codice, nota quanto è migliore il codice che produci e quanto più sei sicuro di quel codice.

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

Linea inferiore: sviluppo più lento, ma pochi difetti, quindi molto meno tempo per correggere i bug.

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

Nello sviluppo guidato dal comportamento ti avvicini ai tuoi biglietti in un modo diverso: ti siedi con la persona d'affari e lavori con loro per definire i comportamenti che questa porzione di funzionalità dovrebbe avere. Lo descrivo in una voce sul mio blog (il titolo del post: Comportamenti di scrittura ).

Sedersi con l'uomo d'affari o chi ti aiuterà a capire meglio che cosa il sistema deve fare per essere felice con quella funzionalità. Cosa deve fare per essere in grado di essere accettato dal processo di controllo della 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 back and forth che ottieni: qualcuno che afferma che la funzionalità è rotta, perché ti sei perso qualcosa (o perché hai perso qualcosa o perché non te ne hanno mai parlato).

Può anche aiutare la percezione altrui della tua squadra: se ti siedi e definisci cosa deve essere fatto nel sistema, potresti passare da "idioti che sovrastimolano tutto e passano il tempo in cose che non chiedevamo" , a "gente intelligente che ha idee utili".

TL; DR: lo sviluppo comportamentale può mostrare miglioramenti rapidamente perché è incentrato sul "cliente". Test Driven Development, per me, sembra riguardare i test interni del codebase a cui "nessuno" importa e dà vantaggi economici meno evidenti. (Lo sviluppo comportamentale ha l'immediato, in faccia, il cambiamento: gli ingegneri stanno improvvisamente avendo molto più tempo per affrontare il "cliente" o l'analista di business per cercare di ottenere ciò giusto - che dovrebbe essere visto come una buona cosa. "Oh , stanno avendo un incontro su Feature X, il che significa che ci sono progressi su questo fronte! ")