Seguire TDD porta inevitabilmente a DI?

14

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 con DI nei costruttori della mia classe. Mi chiedo se ciò sia dovuto a come ho imparato a fare il TDD, o se questo è un effetto collaterale naturale del TDD.

Quindi la mia domanda è questa: seguire i principi del TDD e scrivere test unit che non dipendono da servizi esterni porta inevitabilmente a DI?

tdd dependency-injection inversion-of-control

— Gilles
fonte

8

Sto leggendo The Art of Unit Testing e sembra che porti sicuramente a Dependency Injection (DI).

— programmatore

2

Quindi di che lingua si tratta? DI / etc sono necessari in Java, ma questo è a causa di una limitazione del linguaggio - i linguaggi come Python non ne hanno bisogno poiché possono verificare le dipendenze delle patch nei test.

— Izkata,

@Izkata: sono d'accordo che DI è una soluzione alternativa per una limitazione della lingua; ma il monkeypatch non è necessariamente la stessa cosa in linguaggi meno rigidi. Tra l'altro preferirei funzioni di prima classe, che ti consentono di fare naturalmente ciò che DI si avvicina per disciplina.

— Javier,

19

Seguire TDD e scrivere test unit che non dipendono da database o servizi esterni porta inevitabilmente a DI?

Per ampie definizioni di DI, sì. Le classi non esistono in un vuoto, quindi devono in qualche modo riempire le loro dipendenze. A volte è sufficiente fornire un valore. A volte è necessario fornire una simulazione nel costruttore. A volte tramite contenitori IoC. A volte tramite un accessorio di test privato. Iniettare tutto qualcosa di test nella classe in modo che possa funzionare in modo isolato.

— Telastyn
fonte

9

Per le persone che già conoscono DI, ma non hanno mai visto il punto, penso che i test unitari porteranno quasi invariabilmente a utilizzare DI.

Se non conosci DI e stai cercando di scrivere unit test, alcune persone reinventeranno naturalmente DI, altre saranno frustrate e alla fine scopriranno DI attraverso la ricerca, ma rimarrai sorpreso da quanto spesso non succederà a qualcuno che potrebbe esserci un modo migliore per progettare il loro software per rendere più semplice il testing delle unità. Quelle persone cancellano i test unitari come intrattabili e si arrendono.

— Karl Bielefeldt
fonte

8

I test unitari porteranno a DI (poiché ti costringe a creare unità liberamente accoppiate). TDD non necessariamente, poiché TDD può essere utilizzato anche per la creazione di test strato per strato, anziché test unitari "testuali". Vedi questo articolo

http://stephenwalther.com/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx

per una spiegazione delle differenze.

— Doc Brown
fonte

1

+1 per "TDD non è UT". Anche per riconoscere che l'estremo disaccoppiamento è un risultato comune di UT, non (necessariamente) di TDD.

— Javier,

3

Sì e no: TDD porta alla scrittura di codice ben strutturato, che a sua volta porta a DI.

Con ciò intendo TDD generalmente ti manda la strada giusta per quanto riguarda incapsulamento, SRP e riusabilità. Non si tratta solo di fare alcuni test attorno al codice: si tratta di usare quei test per dare forma a un design migliore. Se un oggetto crea le proprie dipendenze, allora vive in un contesto specifico all'interno di un'applicazione specifica ed è probabile che sia intessuto nell'applicazione in misura maggiore. DI è una buona cosa, non solo dal punto di vista dei test, ma anche dal punto di vista della qualità del codice.

— Tim
fonte

Potresti chiarire la parte negativa della tua risposta sì e no? Come si fa a TDD senza DI.

— Gilles,

Essendo la parte "no" non credo sia un collegamento diretto tra TDD e DI. È indiretto tramite la qualità del codice. Il che probabilmente sta dividendo i peli, ma ho pensato che avrei sottolineato che la qualità del codice è la cosa che stai mirando, non solo la testabilità.

— Tim

0

Come già sottolineato in altre risposte, TDD non richiede test unitari . Puoi anche scrivere test di integrazione / funzionali mentre fai TDD. Tra i vari modi per applicare TDD, la creazione di unit test sarebbe il modo "fingi fino a quando non ce la fai" (vedi il libro di Kent Beck per i dettagli).

Quanto a "TDD porta inevitabilmente a DI", sicuramente no. Ciò di cui uno ha bisogno quando si scrivono test unitari è isolare l'unità da testare dalle implementazioni delle sue dipendenze esterne. E questo può essere fatto altrettanto facilmente con o senza DI. Il modo migliore, probabilmente, è usare un adeguato strumento di isolamento / derisione.

— Rogério
fonte

Ma per usare le beffe non devi necessariamente iniettare le dipendenze nella classe?

— Gilles,