Czy rozwój oparty na testach zmusza mnie do podążania za SOLID?

15

Dużo słyszę od praktyków TDD , że jedną z zalet TDD jest to, że zmusza programistów do przestrzegania zasad SOLID (pojedyncza odpowiedzialność, otwarte zamknięcie, podstawienie Liskowa, segregacja interfejsu i inwersja zależności). Ale jak dla mnie wystarczy napisać kilka testów (przede wszystkim test jednostkowy), aby zrozumieć, że ważne jest, aby postępować zgodnie z SOLID (a tym samym stworzyć architekturę do testowania).

Czy TDD zmusza programistów do aktywniejszego śledzenia SOLID niż pisania testów jednostkowych?

unit-testing tdd solid

— SiberianGuy
źródło

1

TDD polega głównie na zmuszaniu programistów do pisania testów. Więc jeśli powiesz, że pisanie testów jednostkowych powoduje, że piszesz kod SOLID, myślę, że to mówi, że TDD zmusza cię do napisania kodu SOLID. Jest to jednak oparte na tym, co powiedziałeś, i nie odzwierciedla dokładnie mojej opinii, co widać w mojej odpowiedzi.

— Yam Marcovic

1

Yam: Nie będę się zgadzać, TDD nie polega na pisaniu testów jednostkowych. TDD polega na znalezieniu minimalnie złożonego i poprawnego rozwiązania problemu. Testy są tylko produktem ubocznym procedury

— Amit Wadhwa,

TDD z definicji polega na pisaniu testów przed kodem. Teoretycznie możesz stworzyć minimalnie złożone i poprawne rozwiązanie nawet bez testów. Testy po prostu dają natychmiastową informację zwrotną i świadomość regresji. Ponieważ nadal możliwe jest stworzenie zbyt złożonego rozwiązania za pomocą testów, TDD nie polega na tworzeniu minimalnie złożonych rozwiązań per se. To jest przeciwieństwo tego, co powiedziałeś. Eleganckie rozwiązania są produktem ubocznym procedury, a nie odwrotnie.

— Yam Marcovic,

24

Przede wszystkim TDD nie zmusza Cię do pisania kodu SOLID. Możesz zrobić TDD i stworzyć jeden wielki bałagan, jeśli chcesz.

Oczywiście znajomość zasad SOLID pomaga, ponieważ w przeciwnym razie możesz po prostu nie mieć dobrej odpowiedzi na wiele twoich problemów, a tym samym napisać zły kod, któremu towarzyszą złe testy.

Jeśli znasz już zasady SOLID, TDD zachęci Cię do przemyślenia ich i aktywnego korzystania z nich.

To powiedziawszy, niekoniecznie obejmuje wszystkie litery w SOLID , ale zdecydowanie zachęca i promuje napisanie przynajmniej częściowo SOLIDNEGO kodu, ponieważ powoduje, że konsekwencje nie zrobienia tego są natychmiast widoczne i irytujące.

Na przykład:

Musisz napisać oddzielony kod, aby wyśmiewać to, czego potrzebujesz. Jest to zgodne z zasadą inwersji zależności .
Musisz napisać testy, które są jasne i krótkie, abyś nie musiał zbyt wiele zmieniać w testach (które mogą stać się dużym źródłem szumu w kodzie, jeśli zrobisz inaczej). Wspiera to zasadę pojedynczej odpowiedzialności .
Można to spierać, ale zasada segregacji interfejsów pozwala klasom polegać na lżejszych interfejsach, które ułatwiają śledzenie i zrozumienie szyderstwa, ponieważ nie trzeba pytać „Dlaczego nie wyśmiano również tych 5 metod?” Lub co ważniejsze, nie masz dużego wyboru przy podejmowaniu decyzji, którą metodę wyśmiewać. Jest to dobre, gdy tak naprawdę nie chcesz przejrzeć całego kodu klasy przed jego przetestowaniem, i po prostu użyj prób i błędów, aby uzyskać podstawowe zrozumienie tego, jak to działa.

Przestrzeganie zasady Open / Closed może pomóc testom napisanym po kodzie, ponieważ zwykle pozwala na zastąpienie wywołań usług zewnętrznych w klasach testowych, które pochodzą z testowanych klas. W TDD uważam, że nie jest to tak wymagane, jak inne zasady, ale mogę się mylić.

Przestrzeganie zasady podstawiania Liskowa jest świetne, jeśli chcesz zminimalizować zmiany w swojej klasie, aby otrzymać nieobsługiwaną instancję, która akurat implementuje ten sam interfejs o typie statycznym, ale prawdopodobnie nie zdarzy się to we właściwych przypadkach testowych, ponieważ jesteś generalnie nie przejdzie żadnej testowanej przez klasę implementacji swoich zależności w świecie rzeczywistym.

Co najważniejsze, stworzono zasady SOLID, aby zachęcić cię do pisania czystszego, bardziej zrozumiałego i łatwego w utrzymaniu kodu, podobnie jak TDD. Więc jeśli właściwie wykonujesz TDD i zwracasz uwagę na to, jak wygląda twój kod i twoje testy (i nie jest to takie trudne, ponieważ otrzymujesz natychmiastowe informacje zwrotne, API i poprawność), możesz ogólnie mniej martwić się zasadami SOLID.

— Yam Marcovic
źródło

Również, jeśli nie zastosujesz się do zmian w pozycji Otwarta / Zamknięta i Liskov, twoje kpiny później się zepsują. Więc nawet jeśli TDD może nie pomóc w egzekwowaniu OCP i LSP, utworzone testy poinformują cię, kiedy je złamiesz. Bardziej efekt ogólnego testowania, ale nadal warto o nim wspomnieć.

— Jonas Schubert Erlandsson

9

Nie

TDD może ułatwić przestrzeganie dobrych praktyk z powodu ciągłego refaktoryzacji, ale nie zmusza do przestrzegania żadnej zasady. Wystarczy upewnić się, że kod, który piszesz, jest testowany. Podczas pisania kodu możesz przestrzegać dowolnych zasad; lub w ogóle żadnych zasad.

— dietbuddha
źródło

2

Moje zrozumienie zasad SOLID rozszerzyło się o rząd wielkości, kiedy zacząłem robić TDD. Gdy tylko zacząłem myśleć o tym, jak wyśmiewać zależności, zdałem sobie sprawę, że praktycznie każdy komponent w bazie kodu ma potencjalną alternatywną implementację. I o ile łatwiej jest przetestować prosty publiczny interfejs API.

Zapewniło także znacznie lepsze zrozumienie większości wzorów projektowych. Zwłaszcza wzorzec strategii.

— Heath Lilley
źródło

0

Tak : TDD jest głównie dobrą techniką projektową (i jedynie wtórną techniką testowania). Bardzo pomaga to w osiągnięciu solidnych zasad, chociaż (patologiczne) przykłady TDD z dużą ilością zapachów kodu są nadal możliwe.

Związek między TDD a solidnymi zasadami jest kwestionowany (z powyższym wnioskiem) w tym wielkim podcastu Hanselminute o nazwie „Test Driven Development is Design - The Last Word on TDD” .

— DaveFar
źródło