Czy przestrzeganie TDD nieuchronnie prowadzi do DI?

14

Nauczyłem się robić Test Driven Development (TDD), Dependency Injection (DI) i Inversion of Control (IoC) jednocześnie. Kiedy piszę kod za pomocą TDD, zawsze używam DI w konstruktorach mojej klasy. Zastanawiam się, czy to z powodu tego, jak nauczyłem się robić TDD, czy jest to naturalny efekt uboczny TDD.

Moje pytanie brzmi więc: czy przestrzeganie zasad TDD i pisanie testów jednostkowych, które nie zależą od usług zewnętrznych, nieuchronnie prowadzi do DI?

tdd dependency-injection inversion-of-control

— Gilles
źródło

8

Czytam The Art of Unit Testing i wydaje się, że zdecydowanie prowadzi to do Dependency Injection (DI).

— programista

2

Więc o co chodzi w tym języku? DI / etc są niezbędne w Javie, ale jest to spowodowane ograniczeniami językowymi - języki takie jak Python nie potrzebują go, ponieważ mogą małpować zależności łatek w testach.

— Izkata

@Izkata: Zgadzam się, że DI jest obejściem ograniczeń językowych; ale śledzenie małp niekoniecznie jest tym samym w mniej sztywnych językach. Między innymi wolałbym funkcje pierwszej klasy, co pozwala naturalnie robić to, co DI zbliża się do dyscypliny.

— Javier,

19

Czy śledzenie TDD i pisanie testów jednostkowych, które nie zależą od baz danych lub usług zewnętrznych, nieuchronnie prowadzi do DI?

W przypadku szerokich definicji DI, tak. Klasy nie istnieją w próżni, więc muszą jakoś wypełnić swoje zależności. Czasami samo podanie wartości jest w porządku. Czasami musisz podać próbny konstruktor. Czasami za pośrednictwem kontenerów IoC. Czasami za pośrednictwem prywatnego akcesorium testowego. To wszystko wstrzykuje coś testowego do klasy, aby mogło działać w izolacji.

— Telastyn
źródło

9

Dla osób, które już wiedzą o DI, ale nigdy nie widziały sensu, myślę, że testy jednostkowe prawie zawsze prowadzą do użycia DI.

Jeśli nie wiesz o DI i próbujesz pisać testy jednostkowe, niektórzy naturalnie wymyślą DI, inni będą sfrustrowani i ostatecznie odkryją DI na podstawie badań, ale zdziwisz się, jak często komuś to nie przydarzy się że może istnieć lepszy sposób na architekturę ich oprogramowania, aby ułatwić testowanie jednostkowe. Ci ludzie odpisują testy jednostkowe jako trudne i poddają się.

— Karl Bielefeldt
źródło

8

Testy jednostkowe doprowadzą do DI (ponieważ zmusza cię do tworzenia luźno powiązanych jednostek). TDD niekoniecznie, ponieważ TDD może być również używany do tworzenia testów warstwa po warstwie, zamiast „testów dosadnych”. Zobacz ten artykuł

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

dla wyjaśnienia różnic.

— Doktor Brown
źródło

1

+1 dla „TDD nie jest UT”. Również dla uznania, że ekstremalne rozprzęganie jest powszechnym wynikiem UT, a nie (koniecznie) TDD.

— Javier,

3

Tak i nie: TDD prowadzi do napisania dobrze ustrukturyzowanego kodu, który sam prowadzi do DI.

Rozumiem przez to, że TDD ogólnie wysyła właściwą drogę do enkapsulacji, SRP i ponownego użycia. Nie chodzi tylko o przeprowadzenie testów w kodzie: chodzi o wykorzystanie tych testów do opracowania lepszego projektu. Jeśli obiekt tworzy własne zależności, to żyje w określonym kontekście w określonej aplikacji i prawdopodobnie będzie w większym stopniu wpleciony w aplikację. DI jest dobrą rzeczą, nie tylko z testowego punktu widzenia, ale także z punktu widzenia jakości kodu.

— Tim
źródło

Czy możesz wyjaśnić brak części swojego tak i bez odpowiedzi? Jak zrobić TDD bez DI.

— Gilles,

Część „nie” nie wydaje mi się, aby była to bezpośrednia więź między TDD i DI. Jest to pośrednie dzięki jakości kodu. Co prawdopodobnie dzieli włosy, ale pomyślałem, że chciałbym zwrócić uwagę na jakość kodu, a nie tylko na testowanie.

— Tim

0

Jak już wskazano w innych odpowiedziach, TDD nie wymaga testów jednostkowych . Równie dobrze możesz pisać testy integracyjne / funkcjonalne podczas TDD. Spośród kilku sposobów zastosowania TDD, tworzenie testów jednostkowych byłoby sposobem „podróbki, dopóki się nie uda” (szczegóły w książce Kent Beck).

Jeśli chodzi o „TDD nieuchronnie prowadzi do DI”, to na pewno nie. Podczas pisania testów jednostkowych potrzebne jest izolowanie testowanej jednostki od implementacji jej zewnętrznych zależności. Można to zrobić równie łatwo z DI lub bez. Prawdopodobnie najlepszym sposobem jest użycie odpowiedniego narzędzia do izolacji / kpin.

— Rogério
źródło

Ale żeby użyć próbnych elementów, nie musisz koniecznie wstrzykiwać zależności w klasie?

— Gilles