Sviluppo guidato dai test - convincimi! [chiuso]

Ok, alcuni vantaggi per TDD:

1. Significa che finisci con altri test. A tutti piace avere test, ma poche persone come scrivono loro. Costruire il test di scrittura nel flusso di sviluppo significa che si finiscono con più test.
2. Scrivere su un test ti costringe a pensare alla testabilità del tuo design, e il design verificabile è quasi un design sempre migliore. Non mi è del tutto chiaro perché questo sia il caso, ma la mia esperienza e quella della maggior parte degli evangelisti del TDD sembra confermarlo.
3. Ecco uno studio che dice che sebbene TDD impieghi un po 'più tempo per scrivere, c'è un buon ritorno sull'investimento perché ottieni un codice di qualità superiore e quindi meno bug da correggere.
4. Ti dà fiducia nel refactoring. È una bella sensazione essere in grado di cambiare un sistema senza preoccuparsi di rompere tutto il resto perché è abbastanza ben coperto dai test unitari.
5. Non si ottiene quasi mai un bug di ripetizione, dal momento che tutti quelli che trovi dovrebbero ricevere un test prima di ottenere una correzione.

Hai chiesto di essere convinto, quindi questi erano benefici. Vedi questa domanda per una visualizzazione più equilibrata.

Robert C. Martin ha originariamente fatto questi punti: posso confermarli dalla mia esperienza personale:

• Creerai automaticamente una suite di test di regressione di test unitari durante il tuo percorso.
• Quasi non passerai il debug del tempo, come se ti stessi codificando in un buco, è più facile annullare il tuo codice fino al punto in cui è passato l'ultimo test, invece di aprire un debugger crack.
• Ogni pochi minuti verifichi che il tuo codice funzioni - tutto (o almeno tutto il comportamento coperto dai test, che se stai facendo TDD è una percentuale molto alta)

Ho sempre fatto TDD tutto il tempo, sia che io stia lavorando alla produzione o al codice di riproduzione; Trovo difficile da codificare in qualsiasi altro modo in questi giorni.

(Dichiarazione di non responsabilità: praticamente non ho materiale dell'interfaccia utente, quindi non posso discutere di TDD per le interfacce utente.)

Uso TDD praticamente in tutto ciò che faccio, da app banali a interi stack SIP.

Non uso TDD in un sito Web legacy di PHP che ho rilevato. Trovo doloroso non avere test. E trovo estremamente fastidioso rompere accidentalmente parti del sito perché non ho una suite di test di regressione che mi dice che ho rotto qualcosa. Il cliente non ha il budget per me (a) scrivere test per il codebase e (b) nel processo rendere il codice testabile in primo luogo, quindi ho appena sopportato.

• Ogni volta che il tuo cliente può essere fornito in modo più efficace (probabilmente si relazionerà bene con i test) e ridurrà almeno la discussione di fine progetto)
• Ogni volta che impiegherebbe più tempo a mantenere i tuoi co-sviluppatori informati su EVERYTYHING nel codice piuttosto che a impegnarsi a costruire il test - e questo è più presto di quanto potresti pensare

Che cosa? Nessuna risposta negativa!?

Dichiarazione di non responsabilità: non sono un test anti-unità. Quando la gente dice TDD, presumo che intendano la versione dal suono della malattia in cui stanno scrivendo i test prima di scrivere il codice per l'80-100% di tutto il codice che scrivono.

Direi:

• È un attivatore. Se la cattura dei problemi di regressione è un problema così grande per te che il TDD completamente automatico dall'inizio ti sembra utile, scrivere test per ogni ultimo pezzo di codice che scrivi potrebbe effettivamente aiutarti a ignorare il vero problema.

• Aiuta le persone a ignorare il vero problema. Quando si risolve un bug si trasforma in un gioco di whack-a-mole dove altri due pop-up, l'architettura soffia. Messa a fuoco. Concentrati sul vero problema. Vedere le talpe prima che debbano essere picchiati è pulito, ma non dovresti essere lì in primo luogo.

• Mangia molto tempo. Colpisco bug occasionali. Non ne ho presi così tanti che mi sembra utile prefissare ogni nuova cosa che scrivo con un test per questo. Cattura problemi dove potrebbero accadere. Gestire gli errori in modo che siano facili da diagnosticare. Convalidare. Test nei punti chiave di sovrapposizione / collo di bottiglia. Ma per gridare ad alta voce non testare ogni ultimo getter e setter in qualcosa che probabilmente non avrebbe dovuto avere quelli in primo luogo.

• Design Focus: non c'è assolutamente alcun modo anche per un buon sviluppatore di scrivere il miglior codice possibile quando si concentrano anche sul test. Se sembra l'unico modo per avere un design decente, ti consiglio di vedere quanto sopra su "concentrarsi sul vero problema".

• Macro-Design Fail: il codebase al mio attuale lavoro è pieno di interfacce che non vengono mai utilizzate più di una volta e violazioni massicce del principio base di DRY che ho finalmente iniziato a capire quando ho capito che le persone stavano scrivendo per il quadri di prova e test in generale. I test non dovrebbero portare a un'architettura stupida. No davvero, non c'è nulla che sia in qualche modo più scalabile o degno di nota aziendale circa la copia e l'incolla di 20 file e quindi apportare solo modifiche significative a due di essi. L'idea è di separare le preoccupazioni, non di dividerle nel mezzo. Cruft e astrazione inutile ti costeranno di più che non avranno una copertura del 95%.

• È molto popolare e molte persone lo apprezzano davvero. Se questa non è una ragione sufficiente per indovinare e / o controllare la tecnologia prima dell'adozione, imparaci un po 'di paranoia.