Ho imparato a fare Test Driven Development (TDD), Dependency Injection (DI) e Inversion of Control (IoC) allo stesso tempo. Quando scrivo codice usando TDD, finisco sempre per usare DI nei costruttori della mia classe. Mi chiedo se questo è dovuto al modo in cui ho imparato a fare TDD, o se questo è un effetto collaterale naturale di TDD.
Quindi la mia domanda è questa: i seguenti principi TDD e test di unità di scrittura che non dipendono da servizi esterni portano inevitabilmente a DI?
Does following TDD and writing unit tests that do not depend on databases or external services inevitably lead to DI?
Per le definizioni ampie di DI, sì. Le classi non esistono in un vaccuum, quindi hanno bisogno di avere le loro dipendenze riempite in qualche modo. A volte solo fornire un valore va bene. A volte è necessario fornire una simulazione al costruttore. A volte tramite contenitori IoC. A volte tramite un accesso di prova privato. È tutto iniettare qualche cosa di test nella classe in modo che possa funzionare in modo isolato.
Per le persone che già conoscono il DI, ma non ho mai visto il punto, penso che i test unitari porteranno quasi invariabilmente a usare DI.
Se non non sai di DI e stai provando a scrivere test di unità, alcune persone naturalmente reinventeranno DI, alcuni saranno frustrati e alla fine scopriranno DI attraverso la ricerca, ma rimarrai sorpreso Quante volte semplicemente non capiterà a qualcuno che potrebbe esserci un modo migliore di progettare il proprio software per rendere più semplice il test delle unità. Quelle persone cancellano i test unitari come intrattabili e si arrendono.
I test unitari porteranno a DI (dato che ti costringe a creare unità liberamente accoppiate). TDD non necessariamente, dal momento che TDD può essere utilizzato anche per creare test strato per livello, anziché test di unità "verbatim". Vedi questo articolo
per una spiegazione delle differenze.
Sì e no: TDD porta alla scrittura di un codice ben strutturato, che a sua volta porta a DI.
Con questo intendo che TDD generalmente ti invia la strada giusta per quanto riguarda incapsulamento, SRP e riusabilità. Non si tratta solo di fare dei test attorno al tuo codice: si tratta di utilizzare quei test per arricchire un design migliore. Se un oggetto crea le sue dipendenze, allora vive all'interno di un contesto specifico all'interno di una specifica applicazione ed è probabile che venga intessuto nell'applicazione in misura maggiore. DI è una buona cosa, non solo dal punto di vista del test, ma anche dal punto di vista della qualità del codice.
Come già sottolineato in altre risposte, TDD non richiede test unit . Puoi anche scrivere integrazioni / test funzionali mentre fai TDD. Tra i vari modi di applicare il TDD, la creazione di test unitari sarebbe il modo "finto fino a che non lo fai" (vedi il libro di Kent Beck per i dettagli).
Come per "TDD porta inevitabilmente a DI", sicuramente non lo è. Ciò di cui si ha bisogno durante la scrittura dei test unitari è quello di isolare l'unità sottoposta a test dalle implementazioni delle sue dipendenze esterne. E questo può essere fatto altrettanto facilmente con o senza DI. Il modo migliore, probabilmente, è utilizzare un corretto strumento di isolamento / simulazione.
Leggi altre domande sui tag tdd dependency-injection inversion-of-control