Programowanie oparte na testach – jak się do tego przełamać

Programowanie oparte na testach to sposób radzenia sobie ze strachem podczas tworzenia oprogramowania. — Kent Beck

Mamy niewysłowione szczęście! Od dawna dysponujemy programowaniem opartym na testach.

Minęło kilkadziesiąt lat, odkąd programiści, którzy napisali kod dla Programu Mercury, przećwiczyli TDD na kartach dziurkowanych. Na przełomie wieków powstały biblioteki XUnit ułatwiające wdrażanie programowania opartego na testach. Kent Beck, autor książki TDD. Sztuka tworzenia dobrego kodu (Helion, 2014) oraz twórca frameworku JUnit, mówi o sobie, że „odkrył na nowo” (a nie wymyślił) praktykę TDD. To stwierdzenie jest prawdziwe i dowodzi jedynie jego pokory. TDD jest tak stare, jak samo tworzenie oprogramowania.

Dlaczego więc programowanie oparte na testach nadal nie stało się standardowym sposobem pisania kodu? Dlaczego często jest to pierwsza praktyka, z której rezygnuje się pod presją terminów, w przypadku konieczności ograniczenia budżetów IT, lub (moja ulubiona przyczyna), gdy pojawia się dążenie do „zwiększenia szybkości pracy zespołu dostarczającego oprogramowanie”? Podaje się wszystkie te preteksty pomimo łatwej dostępności dowodów empirycznych oraz eksperymentalnych na to, że TDD zmniejsza liczbę usterek, upraszcza projekt i zwiększa zaufanie programistów do własnego kodu.

Dlaczego TDD jest niechętnie przyjmowane i łatwo porzucane? Przyczynę tego stanu rzeczy mogą wyjaśniać przedstawione poniżej argumenty, które są często przytaczane przez osoby nieprzychylne praktykowaniu TDD.

Nie wiem, od czego i jak zacząć

Prawdopodobnie najczęstszym powodem jest brak świadomości i doświadczenia. Jak w przypadku każdej innej umiejętności, pisania kodu w stylu TDD należy się nauczyć. Wielu programistów nie miało zewnętrznego bodźca (czasu, zasobów, wskazówek, zachęty) albo wewnętrznej motywacji (do przezwyciężenia własnej niechęci i strachu), by posiąść tę umiejętność.

TDD sprawdza się w programach-zabawkach lub podczas rozmów kwalifikacyjnych z dziedziny kodowania, ale nie podczas pisania „rzeczywistego” kodu

To nieprawda, ale taka perspektywa jest zrozumiała. Większość przewodników i publikacji (ta nie jest wyjątkiem) dotyczących programowania opartego na testach ogranicza się do wybierania stosunkowo prostych przykładów z oczywistej domeny. Trudno jest napisać artykuł lub książkę o TDD z wykorzystaniem rzeczywistego kodu oprogramowania wyjętego z wdrożonej komercyjnie aplikacji (np. w instytucji finansowej, systemie zarządzania opieką zdrowotną lub autonomicznym samochodzie). Po pierwsze, większość takiego kodu w prawdziwym świecie jest prawnie zastrzeżona i nie jest oprogramowaniem dostępnym na licencji open source. Po drugie, zadaniem autora jest pokazanie kodu z domeny, która jest najbardziej atrakcyjna dla jak największego grona odbiorców. Prezentowanie TDD w kontekście wysoce wyspecjalizowanej dziedziny byłoby nielogiczne, graniczące wręcz z obskurantyzmem. Takie postępowanie wymagałoby przede wszystkim obszernego wyjaśnienia tajemniczego żargonu i gwary danej dziedziny. Byłoby to sprzeczne z samym celem autora, jakim jest uczynienie TDD zrozumiałym, przystępnym, a nawet kochanym.

Pomimo tych przeszkód w korzystaniu z rzeczywistego kodu w literaturze TDD programiści regularnie piszą oprogramowanie produkcyjne przy użyciu programowania opartego na testach. Prawdopodobnie najlepszym i najbardziej przekonującym przykładem jest zestaw testów jednostkowych dla samego frameworku JUnit. Jądro Linuksa — przypuszczalnie najbardziej intensywnie wykorzystywany element oprogramowania na świecie — jest ulepszane za pomocą testów jednostkowych.

Pisanie testów po fakcie jest wystarczające; TDD jest zbyt restrykcyjne i (lub) pedantyczne

Jest to bardziej orzeźwiające stwierdzenie niż okazjonalne narzekanie, że „testy jednostkowe są przereklamowane”! Pisanie testów po napisaniu kodu produkcyjnego to już jakiś postęp w stosunku do niepisania w ogóle żadnych testów. Wszystko, co zwiększa zaufanie programistów do własnego kodu, zmniejsza przypadkową złożoność i zapewnia autentyczną dokumentację, jest pozytywne. Pisanie testów jednostkowych przed napisaniem kodu produkcyjnego stanowi jednak funkcję zapobiegania tworzeniu dowolnej złożoności.

TDD prowadzi nas w kierunku prostszego projektowania, ponieważ stosuje dwie praktyczne.

Zasady:

1. Aby naprawić test kończący się niepowodzeniem, pisz tylko kod produkcyjny.
2. Energicznie refaktoryzuj tylko wtedy, gdy testy są zielone.

*Artykuł stanowi fragment książki pt. „Nauka programowania opartego na testach. Jak pisać przejrzysty kod w kilku językach programowania” Saleem Siddiqui (Helion 2022)