Korzyści z programowania sterowanego testami: kluczowe statystyki i badania

W tym artykule analizuję niektóre statystyki i badania dotyczące programowania sterowanego testami, aby zrozumieć, jak jest ono wykorzystywane, jakie przynosi korzyści oraz z jakimi wyzwaniami mierzą się zespoły stosujące to podejście.

Tradycyjnie proces tworzenia oprogramowania przebiega liniowo. Jednak w ciągu ostatnich kilku dekad, gdy systemy zwinne zyskują coraz większą popularność (nawet 87% zespołów stosuje podejście zwinne lub zbliżone do zwinnego), tworzenie oprogramowania zaczęło uwzględniać różne metodyki, które biorą pod uwagę wymagania i charakter projektu.

Technika programowania sterowanego testami (TDD) jest jedną z metod, które przyciągają uwagę w obszarze zwinnego tworzenia oprogramowania.  

W artykule badawczym opublikowanym przez Institute of Electrical and Electronics Engineers autorzy Yahya Rafique i Vojislav Misic twierdzą, że „programowanie sterowane testami (TDD) należy do kluczowych praktyk procesu tworzenia oprogramowania Extreme Programming (XP)” (Źródło). 

Według doniesień człowiek, któremu przypisuje się opracowanie TDD, „stwierdził w 2003 roku, że TDD zachęca do tworzenia prostych projektów i budzi zaufanie” (Źródło). Nadal jednak pozostają pytania dotyczące twierdzeń na temat produktywności i jakości związanych z TDD. 

Poświęciliśmy trochę czasu na zebranie najnowszych statystyk dotyczących TDD, aby zweryfikować te twierdzenia.

Artykuł rozpoczyna się od zdefiniowania pojęcia TDD oraz wyjaśnienia, czym różni się ono od tradycyjnego podejścia. Następnie przyglądamy się niektórym statystykom, które potwierdzają lub podważają twierdzenia dotyczące TDD.    

Czym jest programowanie sterowane testami?

Programowanie sterowane testami to podejście, w którym test jest pisany, zanim programista utworzy kod produkcyjny spełniający wymagania testu. Podstawowym założeniem tej techniki jest umożliwienie autorowi kodu poświęcenia czasu na przemyślenie projektu lub wymagań przed napisaniem działającego kodu.  

Proces TDD

1. Pisanie testu: W TDD wszystkie nowe funkcje zaczynają się od napisania testu. Programista musi zrozumieć specyfikację i wymagania funkcji. Aby to osiągnąć, powinien przeanalizować historie użytkowników i przypadki użycia, aby zrozumieć cel nowego tworzonego kodu.   
2. Niepowodzenie testu: Po napisaniu testu programista go uruchamia. Ponieważ nie ma jeszcze kodu, który mógłby go obsłużyć, test zakończy się niepowodzeniem. Potwierdza to, że zautomatyzowany system testów działa prawidłowo i wyklucza możliwość, że nowy test zawsze przejdzie, ponieważ jest wadliwy. 
3. Tworzenie kodu: Teraz programista wie, że funkcja działa zgodnie z projektem. Następnie pisze kod, który przechodzi test. Kod może nie być idealny ani doskonale przechodzić testu, ale nie ma to znaczenia. Nie oczekuje się od programisty pisania kodu wykraczającego poza funkcjonalność, którą test miał sprawdzić.
4. Uruchamianie testów: Wiedząc, że funkcja działa zgodnie z projektem, programista może za każdym razem, gdy wydaje nowy kod, użyć narzędzia do zarządzania testami, aby ponownie uruchomić ten test. Otrzymuje w ten sposób potwierdzenie, że najnowsza aktualizacja nie uszkodziła wcześniejszej funkcji.  
5. Refaktoryzacja kodu: W TDD baza kodu musi być stale porządkowana w miarę jej rozrastania się. Ponieważ na wcześniejszych etapach głównym celem programisty było wyłącznie napisanie kodu, ten etap zapewnia efektywność. Umożliwia ulepszanie wewnętrznej struktury kodu źródłowego programu przy jednoczesnym zachowaniu jego zewnętrznych cech. Na tym etapie można usunąć duplikaty i dodać nowe funkcje.   
6. Powtórzenie: Powyższe kroki są automatycznie powtarzane, aby zapewnić, że cykle TDD obejmują wszystkie funkcje.  

Różnice między TDD a tradycyjnym tworzeniem oprogramowania

Aby zrozumieć TDD, warto określić, czym różni się ono od tradycyjnych metod programowania.

Główna różnica polega na tym, że tradycyjne metody stosują proces liniowy, podczas gdy TDD przebiega cyklicznie. 

Programiści korzystający z tradycyjnych metod testowania zaczynają od stworzenia kodu i skupiają się na teście dopiero pod koniec procesu tworzenia oprogramowania. Z kolei osoba stosująca model TDD zaczyna od stworzenia testu, a następnie opracowuje kod, który go spełnia. To podejście ma wiele wspólnych zasad z ruchem przesuwania testów w lewo w testowaniu oprogramowania.

Programista korzystający z tradycyjnego podejścia może skupić się na poprawności kodu, ale ryzykuje niewykrycie wszystkich błędów w kodzie. Programista stosujący metodę TDD pracuje nad kodem, aż przejdzie on test, refaktoryzując go. Proces ten trwa do momentu, gdy kod spełnia wymagania funkcjonalne, co prawdopodobnie prowadzi do mniejszej liczby błędów.

Czy TDD jest wolniejsze czy szybsze od tradycyjnego tworzenia testów?

Jeśli chodzi o to, czy TDD przyspiesza proces programowania, dane statystyczne z różnych źródeł są sprzeczne. 

Studium przypadku obejmujące zespoły inżynierów oprogramowania z firm Microsoft i IBM wykazało, że „zespoły odnotowały wzrost początkowego czasu tworzenia o 15–35%”, gdy stosowały technikę TDD. W badaniu zaznaczono jednak, że są to wartości „subiektywnie oszacowane przez kierownictwo” (Źródło). 

Jeśli spojrzeć na to z perspektywy wskazującej, że badania firm Microsoft i IBM wykazały poprawę jakości, można argumentować, że w dłuższej perspektywie TDD oszczędza czas, który trzeba byłoby poświęcić na naprawianie problemów. Zespoły firm Microsoft i IBM zgodziły się z tym poglądem (Źródło). 

Badanie koncentrujące się na początkowych odczuciach doświadczonych specjalistów korzystających z TDD wykazało, że „po pokonaniu początkowych trudności związanych ze zrozumieniem, od czego zacząć, oraz z wiedzą, jak utworzyć test dla funkcji, która jeszcze nie istnieje, uczestnicy zyskują większą pewność siebie przy implementowaniu nowych funkcji i wprowadzaniu zmian dzięki szerokiemu pokryciu testami” (Źródło). Wydaje się to sugerować, że z czasem sytuacja się poprawia. 

Programista i autor „Composing Software” i „Programowanie aplikacji JavaScript”, Erick Elliot, pisząc dla internetowej platformy wydawniczej Medium.com, skupia się na tym, jak TDD zmieniło jego życie. Elliot zgadza się, że na początku proces może być powolny, ale mówi: „gdzieś około drugiego roku coś magicznego zaczęło się dziać: zacząłem programować szybciej z użyciem testów jednostkowych niż kiedykolwiek wcześniej bez nich” (Źródło).  

Wygląda na to, że korzystanie z TDD może początkowo spowalniać pracę. Jeśli jednak spojrzeć na to z perspektywy długoterminowej, czas zaoszczędzony dzięki kodowi o wyższej jakości może zrekompensować czas stracony na początku. Można również oczekiwać, że w miarę zdobywania przez programistów większego doświadczenia w TDD będą oni prawdopodobnie pracować szybciej. 

Przy próbie zmierzenia czasu potrzebnego do uzyskania rezultatu wysokiej jakości należy również wziąć pod uwagę wiele innych czynników. Więcej informacji na ten temat można znaleźć w odcinku podcastu The QA Lead poświęconym pomiarowi T2Q (Czasu do uzyskania jakości), prowadzonym przez Nialla Lyncha.

Czy TDD prowadzi do mniejszej liczby błędów?  

W powyższej dyskusji jedną z głównych zalet TDD jest to, że prowadzi ono do mniejszej liczby błędów. Czy statystyki to potwierdzają? 

Te same badania obejmujące zespoły inżynierskie firm Microsoft i IBM wykazały, że „gęstość defektów przed wydaniem w czterech produktach zmniejszyła się o 40–90% w porównaniu z podobnymi projektami, które nie stosowały praktyki TDD”. W szczególności zespoły IBM odnotowały spadek gęstości defektów o 40%, a zespoły Microsoft — o 60–90% (Źródło). 

Czy statystyki dotyczące tworzenia oprogramowania sterowanego testami potwierdzają wniosek, że TDD zapewnia wyższą jakość?

Na podstawie wyników badania przedstawionego podczas pierwszego międzynarodowego sympozjum IEEE w Finlandii w 2007 roku Maria Siniaalto i Pekka Abrahamsson informują, że wykazano, iż TDD zapewnia lepszą jakość kodu w porównaniu z oprogramowaniem tworzonym bez TDD (Źródło). 

W swoim artykule Siniaalto i Abrahamsson przywołują badanie przeprowadzone w Chinach, z którego wynika, że TDD usprawniło śledzenie procesu i szacowanie zadań. To samo badanie wykazało, że „TDD przyczynia się również do przestrzegania spójnych praktyk i wytycznych”. Skutkuje to lepszą jakością i mniejszą liczbą defektów. Ponadto zespoły korzystające z TDD były w stanie szybciej naprawiać defekty (Źródło).  

W badaniu przeprowadzonym wśród programistów, mających średnio około dziesięciu lat doświadczenia zawodowego, którego celem było zbadanie ich postrzegania pracy z wykorzystaniem TDD, przytoczono wypowiedź programisty: „TDD pomogło mi ulepszyć kod i uczynić go bardziej czytelnym”. Inny uczestnik stwierdził, że „TDD umożliwia łatwiejsze utrzymanie kodu” (Źródło).  

Czy TDD sprzyja prostszemu projektowaniu?

Boby George i Laurie Williams, pracujący na Wydziale Informatyki Uniwersytetu Stanowego Karoliny Północnej, przeprowadzili eksperyment, w którym 24 programistów podzielono na dwie grupy: jedna korzystała z TDD, a druga z podejścia liniowego.

George i Williams informują, że spośród uczestników „92% programistów uważało, że TDD prowadzi do kodu wyższej jakości, 79% sądziło, że TDD sprzyja prostszemu projektowaniu, a 71% uznało to podejście za wyraźnie skuteczne” (Źródło).  

Te statystyki dotyczące jakości wytwarzania oprogramowania sterowanego testami wyraźnie wskazują, że TDD rzeczywiście prowadzi do kodu wyższej jakości i prostszego projektu.

W artykule opublikowanym przez bezpłatny portal edukacyjny Guru99.com Kanchan Kulkarni stwierdza: „TDD sprawia, że kod jest prostszy i przejrzysty. Pozwala programiście ograniczyć ilość dokumentacji” (Źródło). 

Czy łatwo jest wdrożyć projektowanie TDD?

W eksperymencie George'a i Williamsa 56% profesjonalnych programistów uważało, że trudno jest przyjąć sposób myślenia charakterystyczny dla TDD, a 23% twierdziło, że przyczyną tej trudności jest brak początkowej fazy projektowania. Spośród wszystkich respondentów 40% uważało, że wdrożenie TDD jest trudne (Źródło).

Te statystyki dotyczące wdrażania wytwarzania oprogramowania sterowanego testami wskazują, że TDD jest postrzegane jako trudne do wdrożenia.

Czy TDD jest przeceniane? 

W artykule opublikowanym na Medium.com Tylor Borgeson, który określa się jako programista pełnego stosu oprogramowania zainteresowany uczeniem maszynowym, sztuczną inteligencją, infrastrukturą, DevOps i metodykami zwinnymi, używa nagłówka „Wytwarzanie oprogramowania sterowane testami jest przeceniane”. Jednak fakt, że umieścił ten nagłówek w cudzysłowie, pokazuje, że nie jest to stwierdzenie, z którym się utożsamia.  

Borgeson zwraca się następnie do osób, które twierdzą, że ta metoda jest przeceniana i powolna, mówiąc im, że większość osób podzielających ten pogląd nie korzystała z niej wystarczająco długo. Kończąc artykuł, stwierdza: „Teraz ćwicz wytwarzanie oprogramowania sterowane testami, aż przestanie sprawiać ci ból” (Źródło).

Co dalej?

Poznaj podejścia do zapewniania jakości od ekspertów w podcaście The QA Lead

Zapisz się do newslettera The QA Lead, aby otrzymywać nasze najnowsze poradniki i odcinki podcastu

Dołącz do listy oczekujących na forum internetowej społeczności The QA Lead, gdzie możesz dzielić się najlepszymi praktykami z innymi specjalistami ds. zapewniania jakości i testowania oprogramowania.

Mamy nadzieję, że się tam zobaczymy!