Czy korzystanie z AutoMocking pojemników dobre czy złe praktyki?

Question

Niedawno pracowałem nad projektem, który stał się ciężki i zależał od tego, jak wykorzystać kontener z AutoMockingiem, aby nieco uprzątnąć moje testy i zmniejszyć ich łamliwość.

Słyszałem argumenty przeciwko używaniu ich przez purystów TDD/BDD, stwierdzając takie rzeczy jak: Nie jest od razu oczywiste, które zależności są wymagane przez podmiot testowy, lub można dodać zależności, których naprawdę nie potrzebujesz. Żaden z nich nie brzmi jak szczególnie silny argument przeciwko używaniu ich.

Z mojego punktu widzenia wprowadzenie go umożliwiłoby mi refaktoryzację zgodnie z wymaganiami, usunięcie i wprowadzenie zależności zgodnie z wymaganiami biznesowymi, bez konieczności ciągłego powracania do testów i wprowadzania nowych mocks/stubów tylko po to, aby kod mógł zostać skompilowany.

Czy automatyczne blokowanie jest uważane za dobrą/złą praktykę? Czy istnieją szczególne sytuacje, w których należy lub nie należy ich używać?

Answer 1

Podobnie jak w przypadku każdego narzędzia lub procesu, są to poprawne czasy i niepoprawne godziny ich użycia. Nic nie jest srebrną kulą. Musisz zadać sobie pytanie: "Czy to pomoże mi w wykonaniu mojej pracy?" Pod koniec dnia naszym zadaniem jest zapewnienie jak największej wartości biznesowej, jaką możemy zarobić.
Podczas tworzenia greenfield automatyzacja nie jest tak pomocna. Wszystko powstaje od zera, a technika TDD/BDD z "tradycyjnym" kpieniem działa świetnie. Teoretycznie zależności nie zmieniają się drastycznie, a kiedy tak się dzieje, dobrze jest wiedzieć, kiedy coś psuje.

W trybie konserwacji (lub w przypadku starszej wersji bazy kodowej) automatyzacja może okazać się wyjątkowo korzystna. Na przykład masz za zadanie sprzątanie długu technicznego. Będzie to prawdopodobnie wiązało się z koniecznością refaktoryzacji, a możliwość odizolowania testów od tych zmian jest ogromnym problemem. Należy pamiętać, że jeśli twój kod ma wiele zależności, prawdopodobnie zrywa SOLID i SOC, i będziesz (lub przynajmniej powinien) mieć wiele testów, które nie wykorzystują wszystkich zależności. Dlatego automatyzacja w tym przypadku jest wyjątkowo korzystna. Oczywiście istnieje wiele innych przykładów, w których również pomaga.

Podobnie jak w przypadku każdego narzędzia, musisz się upewnić, że nie stanie się kulą. Wykorzystanie automatyzacji, aby można było zmieniać interfejsy i apisy, nie ma oczywiście charakteru zapobiegawczego. Ale kiedy są prawidłowo stosowane, okazało się, że jest to ogromna korzyść dla naszych zespołów projektowych.

To wymaga krytycznej myśli i zastosowania we właściwych scenariuszach.

Answer 2

Ręczne okablowanie swoich zależności (i pamiętaj, że w testach jednostkowych twoje zależności powinny dotyczyć bardzo małej liczby obiektów tematycznych (jeden)) daje ci znać, kiedy masz zapach - Ta klasa jest zbyt cholernie duża i powinna być wyciąć. Powiedział, że nie sądzę, że auto kpiarstwo jest złe, ale jak każde narzędzie powinno być używane z rozwagą.

Answer 3

Auto szyderstwo zaczyna być przydatne właśnie w tym punkcie, w którym zależności zaczynają śmierdzieć. Zarówno odpowiedź Skimedica, jak i komentarz przez levelnis wskazują na to samo. Tak więc ta praktyka powinna być ogólnie rzecz biorąc unikana , z wyjątkiem przypadków, w których nie można pozbyć się długu spuścizny/technologii. Nawet w niektórych przypadkach wydaje mi się, że lepiej jest zachowywać się tak, jakby nie istniało auto kpiarstwo, a zmniejszona prędkość zespołu to kolejny powód, by zmusić kierownictwo do rozważenia, że ​​jakiś refaktor jest w porządku; lub, jeśli jest to jakaś nieunikniona spuścizna, następnie zaprogramuj swoich fałszywych budowniczych; dodatkowa złożoność testu będzie lepszym wskaźnikiem "strefy niebezpiecznej" niż po prostu przy użyciu auto kpiny i pozornie prostych testów.

I, IMO, nie powinieneś używać go w ogóle z nowym kodem.