Sviluppo guidato dai test - convincimi! [chiuso]

So che alcune persone sono grandi sostenitori dello sviluppo guidato dai test. Ho usato test unitari in passato, ma solo per testare operazioni che possono essere testate facilmente o che credo siano probabilmente corrette. La copertura del codice completa o quasi completa sembra richiedere molto tempo.

1. Per quali progetti usi lo sviluppo test-driven? Lo usi solo per progetti oltre una certa dimensione?
2. Dovrei usarlo o no? Convincimi!

Ok, alcuni vantaggi per TDD:

1. Significa che finisci con altri test. A tutti piace fare i test, ma a pochi piace scriverli . Incorporare la scrittura di prova nel flusso di sviluppo significa che si finiscono con più prove.
2. Scrivere in un test ti costringe a pensare alla testabilità del tuo design e il design testabile è quasi sempre un design migliore. Non è del tutto chiaro per me perché questo accada, ma la mia esperienza e quella della maggior parte degli evangelisti TDD sembrano confermarlo.
3. Ecco uno studio che afferma che sebbene TDD impieghi un po 'più di tempo per scrivere, c'è un buon ritorno sugli investimenti perché ottieni un codice di qualità superiore e quindi meno bug da correggere.
4. Ti dà fiducia nel refactoring. È una grande sensazione poter 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, poiché tutti quelli che si trovano dovrebbero avere un test prima di ottenere una correzione.

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

Robert C. Martin originariamente ha sottolineato questi punti: posso supportarli dalla mia esperienza:

• Costruirai automaticamente una suite di test di regressione di unit test man mano che procedi.
• Non passerai quasi mai il debug del tempo, come se ti stessi codificando in una buca, è più facile annullare il codice al punto in cui è passato l'ultimo test, piuttosto che aprire un debugger.
• 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 di esso).

Praticamente faccio TDD tutto il tempo, sia che stia lavorando alla produzione o che suoni un codice; Al giorno d'oggi trovo difficile codificare diversamente.

(Dichiarazione di non responsabilità: non faccio quasi nulla sull'interfaccia utente, quindi non posso discutere di TDD per le interfacce utente.)

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

Non utilizzo TDD in un sito Web PHP legacy che ho acquisito. Trovo doloroso non avere prove. E trovo intensamente 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 per (a) scrivere test per la base di codice e (b) nel processo per 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 ai test - e almeno ridurrà la discussione di fine progetto)
• Ogni volta che impiegherebbe più tempo a tenere informati i tuoi co-sviluppatori su TUTTO nel codice che a impegnarsi nella costruzione del test - e questo è prima di quanto si possa pensare

Che cosa? Nessuna risposta negativa !?

Disclaimer: non sono un test anti-unità. Quando le persone dicono TDD, presumo che intendano la versione che suona la malattia in cui scrivono test prima di scrivere il codice per l'80-100% di tutto il codice che scrivono.

Direi:

• È un fattore abilitante. Se la cattura di problemi di regressione è un problema così grande per te che TDD full-auto dall'inizio 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 in cui due altri pop-up, l'architettura esplode. Messa a fuoco. Concentrati sul vero problema. Vedere le talpe prima che debbano essere colpite è pulito, ma non dovresti essere lì in primo luogo.

• Mangia molto tempo. Ho colpito bug occasionali. Non ne colpisco così tanti che sembra utile aggiungere un prefisso a ogni nuova cosa che scrivo con un test. Problemi di cattura in cui è probabile che si verifichino. 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 tutti gli ultimi getter e setter in qualcosa che probabilmente non avrebbe dovuto avere quelli in primo luogo.

• Design Focus: non c'è assolutamente modo che anche un bravo sviluppatore scriva il miglior codice possibile quando si stanno anche concentrando sul test. Se sembra l'unico modo in cui puoi avere un design decente, ti consiglio di vedere quanto sopra su "concentrarsi sul problema reale".

• Macro-design Fail: la base di codice nel mio attuale lavoro è piena di interfacce che non vengono mai utilizzate più di una volta e enormi violazioni del principio DRY di base che ho iniziato a capire solo quando ho realizzato che le persone scrivevano per i framework di test e test in generale. I test non dovrebbero portare a stupide architetture. No davvero, non c'è nulla che sia in qualche modo più scalabile o degno dell'impresa nel copiare e incollare 20 file e apportare solo modifiche significative a due di essi. L'idea è quella di separare le preoccupazioni, non dividerle nel mezzo. La cruft e l'astrazione inutile ti costeranno più che non avere mai una copertura del 95%.

• È molto popolare e molta gente piace davvero. Se questa non è una ragione sufficiente per almeno indovinare e / o vagliare la merda di qualsiasi tecnologia prima dell'adozione, impara un po 'di paranoia.