Quali sono alcuni malintesi comuni sul TDD?

Question

Rileggendo le risposte a questa domanda Svantaggi dello sviluppo basato sui test? Ho l'impressione che ci siano molti malintesi su cosa sia il TDD e su come dovrebbe essere condotto.Potrebbe rivelarsi utile affrontare questi problemi qui.

Answer 1

Sento che la risposta accettata è stata una delle più deboli (Svantaggi dello sviluppo basato sui test?), e la risposta più modificata odora di qualcuno che potrebbe scrivere su test specifici.

Investimento importante:Per il semplice caso si perde circa il 20% dell'implementazione effettiva, ma per casi complicati perdi molto di più.

Il TDD è un investimento.Ho scoperto che una volta che sono entrato completamente nel TDD, il tempo che ho perso è davvero molto poco, e il tempo che ho perso è stato più che compensato quando si trattava di tempo di manutenzione.

Per casi complessi i casi di test sono più difficili da calcolare, suggerirei in casi come quello per cercare di utilizzare il codice di riferimento automatico che verrà eseguito in parallelo nella versione di debug / test di test, anziché il test unitario dei casi più semplici.

Se i tuoi test stanno diventando molto complessi, potrebbe essere il momento di rivedere il tuo progetto.TDD dovrebbe guidarti lungo il percorso di unità di codice più piccole e meno complesse che lavorano insieme

A volte il design non è chiaro all'inizio e si evolve man mano che procedi: questo ti costringerà a rifare il test, il che genererà una grande perdita di tempo.Suggerirei di posticipare i test unitari in questo caso finché non avrai in mente una certa comprensione del progetto.

Questo è il punto peggiore di tutti!Il TDD dovrebbe davvero essere "Test Driven". Progetto".TDD riguarda la progettazione, non i test.Per realizzare appieno il valore dei vantaggi del TDD, hai un giocattolo guidare il tuo progetto dai tuoi test.Quindi dovresti esserlo rifare il codice di produzione per far passare i test, non viceversa come suggerisce questo punto

Ora il più aggiornato attualmente: Svantaggi dello sviluppo basato sui test?

Quando arrivi al punto in cui hai un gran numero di test, la modifica del sistema potrebbe richiedere la riscrittura di alcuni o tutti i tuoi test, a seconda di quali sono stati invalidati dalle modifiche.Ciò potrebbe trasformare una modifica relativamente rapida in una modifica che richiede molto tempo.

Come il primo punto delle risposte accettate, questo sembra un eccesso di specifiche nei test e una generale mancanza di comprensione del processo TDD.Quando apporti modifiche, inizia dal test.Cambia il test per sapere cosa dovrebbe fare il nuovo codice e apporta la modifica.Se quel cambiamento interrompe altri test, allora i tuoi test stanno facendo quello che dovrebbero fare, fallendo.I test unitari, per me, sono progettati per fallire, ecco perché la fase ROSSA è la prima e non dovrebbe mai essere persa.

Answer 2

IMHO Il più grande malinteso sul TDD è che: il tempo dedicato alla scrittura e al refactoring dei test sarebbe tempo perso. Il pensiero è: "sì, una suite di test è carina, ma la funzionalità verrebbe completata molto più velocemente se la codificassimo".

Se eseguito correttamente, il tempo impiegato per scrivere e mantenere i test viene risparmiato più volte nel corso della vita del progetto non speso per il debug e la correzione delle regressioni.Poiché il costo del test è anticipato e il profitto è nel tempo, è facile trascurarlo.

Altri grandi malintesi includono ignorare l'impatto di TDD sul processo di progettazione e non rendersi conto che i "test dolorosi" sono un grave odore di codice che deve essere risolto rapidamente.

Answer 3

Vedo molte persone che fraintendono quali test siano effettivamente utili per TDD.Le persone scrivono grandi test di accettazione invece di piccoli test unitari e poi passano troppo tempo a mantenere i loro test e poi concludono che TDD non funziona.Penso che quelli del BDD abbiano ragione nell'evitare del tutto l'uso della parola test.

L'altro estremo è che le persone smettono di eseguire test di accettazione e pensano che, poiché eseguono test unitari, il loro codice viene testato.Anche questo è un malinteso sulla funzione di un test unitario.Hai ancora bisogno di test di accettazione di qualche tipo.

Answer 4

L’idea sbagliata che vedo spesso è che il TDD garantisca buoni risultati.

Spesso i test vengono cancellati da requisiti errati e, pertanto, gli sviluppatori producono un prodotto che non fa ciò che l'utente si aspetta.La chiave del TDD è, a mio avviso, lavorare con gli utenti per definire i requisiti aiutandoli a gestire le loro aspettative.

Answer 5

Queste sono le questioni che a mio avviso sono piuttosto controverse e quindi soggette a malintesi:

• Nella mia esperienza il vantaggio più grande è produrre codice di gran lunga migliore al costo di molto tempo dedicato alla scrittura dei test.Quindi vale davvero la pena per progetti che richiedono alta qualità, ma su altri siti meno incentrati sulla qualità, il tempo extra non varrà lo sforzo.

• Le persone sembrano pensare che solo un sottoinsieme importante delle funzionalità debba essere testato, ma in realtà IMHO è sbagliato.È necessario testare tutto affinché il test sia valido dopo il refactoring.

• Il grande svantaggio del TDD è il falso senso di sicurezza dato da test incompleti:Ho visto siti chiudere perché le persone presumevano che il test unitario fosse sufficiente per attivare una distribuzione.

• Non sono necessari framework beffardi per eseguire TDD.È solo uno strumento per testare alcuni casi in modo più semplice.I migliori unit test, tuttavia, vengono eseguiti in alto nello stack e dovrebbero essere agnostici sui livelli del codice.Testare uno strato alla volta non ha senso in questo contesto.

Answer 6

Sto solo mettendo un'altra risposta nel piatto.

Uno dei malintesi più comuni è che your il codice è fisso, cioè.Ho questo codice, ora come diavolo farò a testarlo?Se è difficile scrivere un test, dovremmo porre la domanda:come posso modificare questo codice per semplificare il test?

Perché..?

Bene, il tipo di codice facile da testare è:

1. Modulare: ogni metodo fa una cosa.
2. Parametrizzato: ogni metodo accetta tutto ciò di cui ha bisogno e restituisce tutto ciò che dovrebbe.
3. Ben specificato: ogni metodo fa esattamente quello che dovrebbe, né più né meno.

Se scriviamo un codice in questo modo, testare è un gioco da ragazzi.La cosa interessante è che il codice facile da testare è, guarda caso, codice migliore.

Meglio perché più facile Leggere, più facile da test, più facile da capire, più facile da eseguire il debug.Questo è il motivo per cui il TDD viene spesso descritto come un esercizio di progettazione.