Pamiętam jak chciałem nauczyć się pisania testów. Szukałem wskazówek w Internacie oraz literaturze no i natrafiłem na TDD, czyli ‘Test-Driven Development’. Wraz z zagłębianiem się w tajniki tej techniki uznałem, że jest to lek na całe zło! Oczywiście wszyscy pisali, że trzeba być zdyscyplinowanym, aby wytrenować w sobie nawyk tworzenia testów w pierwszej kolejności i, że to nie jest takie proste. Jednak takie programowanie wynagradza nam tym, że mamy kod działający w sposób jaki planowaliśmy oraz jest całkowicie pokryty testami. Jednak czy podążając ślepo za “red, green, refactor” możemy zostać zwolnieni z myślenia nad daną funkcjonalnością?
Przykład z neta
Przeglądając Internety natrafiłem na artykuł Maćka Aniserowicza dotyczący właśnie TDD i “czy ono chroni nas przed głupotą?”. Przyznam, że przykład tam zamieszczony świetnie oddaję ideę, dlaczego zawsze musimy myśleć o tym co robimy. Nie istnieje takie narzędzie, które zwalniałoby nas z myślenia. Możemy się nimi posługiwać, aby ułatwić nam pracę jednak to my zawsze jesteśmy odpowiedzialni za to co wytwarzamy. Przykład na stronie Maćka jest napisany w C#, ale jest trywialny i powinien zostać łatwo zrozumiany przez każdego programistę.
Dodatkowo na WJUGu 268 usłyszałem prezentację Jakuba Pilimona na temat testów. Na jednej części omawia on właśnie TDD pokazując czy prowadzi nas ono do dobrego design. Poniżej zamieszczam tą prelekcję tylko z DNA Conf 2020.
Zgadzam się ze stwierdzeniem, że TDD nie kreuje nam designu. To my ukierunkowujemy naszą aplikację, tworzymy ją w taki sposób, aby spełnić wymagania biznesowe. ‘Test-Driven Development’ może nam tylko pomóc to osiągnąć podczas wytwarzania oprogramowania. Musimy najpierw sami poznać naszą domenę, a dopiero później możemy brać się za implementację, bo inaczej zostaniemy z ładnym API ukrywającym bajzel w kodzie. TDD będzie nam tylko pomagało go schować, nie wysteruje nas do pięknego designu.
Kod vs API
Moim zdaniem TDD jest bardzo przydatnym narzędziem, ale właśnie, jest tylko narzędziem. Nie jest on techniką ‘Test-Driven Design’, która ma nam stworzyć design i zwolnić nas z jakiegokolwiek myślenia. Musimy myśleć niskopoziomowo (jak w przykładzie Maćka Aniserowicza) oraz wysoko poziomowo (tak jak to ma miejsce w prezentacji Jakuba Pilimona), aby stworzyć oprogramowanie spełniające postawione założenia. TDD dobrze stosowane będzie nas tylko wspierać, abyśmy nie zbłądzili podczas implementacji.
Podsumowanie
Nie ważne z jakich danych nam dobrodziejstw będziemy korzystać to my jesteśmy odpowiedzialni za naszą aplikację. Musimy spędzić czas na analizie naszej domeny, aby wziąć się za programowania będąc wspieranym przez narzędzia, które mają nam ułatwić życie.
TDD nie chroni przed głupotą. TDD nie zwalnia z myślenia. TDD nie zrobi z nas geniuszy.
devstyle.pl
Polecam też zajrzeć do mojego artykułu, dlaczego warto w ogóle pisać testy.
Życzę Wam dobrego dnia!