È interessante notare che recentemente Justin Searls ha scritto un post sul blog che copre questo argomento. Ha identificato 6 cause che potrebbero generare il dolore che stai sperimentando usando TDD e suggerire un approccio diverso per imparare TDD.
Penso che possa riguardare ciò che stai descrivendo nel tuo flusso di lavoro.
Ecco un riepilogo dei 6 diversi errori identificati da Justin quando si applica TDD.
- Failure #1: Encouraging Large Units
- Failure #2: Encouraging Costly Extract Refactors
- Failure #3: Characterization Tests of Greenfield Code
- Failure #4: Redundant test coverage
- Failure #5: Eliminating Redundancy Sacrifices Regression Value
- Failure #6: Making a Mess with Mocks
In risposta a questo post, lo zio Bob distrugge tutto. ( con un'eccezione riguardante l'architettura / design in alto).
Fondamentalmente lo zio Bob ci ricorda i principi fondamentali alla base di TDD. E questo è dove penso che troverai la tua risposta.
- Codifica prima il test. (test fallisce (rosso))
- Codifica la logica (test è verde)
- Refactor per rendere il tuo codice leggibile e mantenibile.
Uncle Bob dice:
... the Author argues that the new smaller units need new unit tests. That's news to me. I certainly don't rewrite my tests just because I extracted some functions or classes.
TDD è la pratica da provare per prima. Non richiede che una classe abbia il test unitario associato. Finché stai provando prima. Assicurati che l'intenzione dei tuoi test sia molto chiara e specifica. Ti aiuterà a rettificare correttamente il tuo codice (una volta che il test è verde), identificando correttamente le diverse responsabilità e interfacce che devi estrarre.
Inoltre mi assicuro che i miei test siano leggibili in quanto potrebbero essere letti come una forma di documentazione che specifica l'intenzione dietro al codice. A volte ciò implica che devo rifattirli e potrei finire con i test unitari per le mie diverse classi, o forse non del tutto.
Uncle Bob termina il suo articolo con un buon materiale per l'architettura. Spiega quando fare il front design e quando non farlo. Fondamentalmente, lo fai quando sai che ci sarà una separazione di preoccupazione. Ecco cosa dice a riguardo:
... So our up front decisions can be limited to choosing a user experience, and choosing the architectural pattern that is most consistent with that user experience. Once those choices are made, we can TDD the problem domain into existence.
Spero che troverai utili quei due post del blog. Mi è sicuramente piaciuto leggerli.
