Co to jest Test Driven Development, podejścia i zalety

Test Driven Development (TDD) to podejście do tworzenia oprogramowania, w którym opracowywane są przypadki testowe w celu określenia i sprawdzenia, co zrobi kod.

Praktycznie przypadki testowe dla każdej funkcji są tworzone i testowane przed wydaniem oprogramowania, a jeśli test się nie powiedzie, nowy kod jest zapisywany (lub przepisywany lub poprawiany), aby przejść test i uczynić kod prostym i wolnym od błędów.

Test Driven Development (TDD) zaczyna się od zaprojektowania i opracowania testów dla każdej małej funkcji aplikacji. Framework TDD instruuje programistów, aby pisali nowy kod tylko wtedy, gdy automatyczny test się nie powiedzie. Takie podejście pozwala uniknąć powielania kodu. Kompletny moduł TDD to programowanie oparte na testach.

Test Driven Development (TDD) powstał jako część większego paradygmatu projektowania oprogramowania znanego jako Extreme Programming (XP), który jest częścią metodologii tworzenia oprogramowania Agile.

Prosta koncepcja TDD polega na napisaniu i naprawieniu nieudanych testów przed napisaniem nowego kodu (przed opracowaniem). Pomaga to uniknąć powielania kodu, ponieważ piszemy niewielką ilość kodu na raz, aby przejść testy. (Testy to nic innego jak warunki wymagań, które musimy przetestować, aby je spełnić).

Programowanie sterowane testami to proces opracowywania i uruchamiania automatycznych testów przed faktycznym rozwojem aplikacji. Dlatego też TDD jest czasami nazywane Test First Development.

Fazy ​​podejścia TDD

Przed napisaniem jakiegokolwiek nowego kodu programista musi najpierw utworzyć test jednostkowy, który zakończył się niepowodzeniem. Następnie programista — para lub motłoch — tworzy tyle kodu, aby spełnić to wymaganie. Po pomyślnym zakończeniu testu programista może dokonać refaktoryzacji projektu, wprowadzając ulepszenia bez zmiany zachowania.

Chociaż TDD koncentruje się na interakcjach programistów na poziomie jednostki, istnieją inne popularne metody, takie jak programowanie oparte na testach akceptacyjnych (ATDD) lub programowanie oparte na zachowaniu (BDD), które koncentrują się na testach zrozumiałych dla klientów.

Metody te polegają na budowaniu rzeczywistych przykładów w postaci wspólnych testów między personelem inżynieryjnym a klientem przed kodowaniem, a następnie przeprowadzaniu testów po kodowaniu w celu wykazania, że ​​kod został zaimplementowany. Znajomość testów z wyprzedzeniem poprawia jakość za pierwszym razem. ATDD i BDD wymagają współpracy programistów, testerów i strony biznesowej w celu wyobrażenia sobie i przedyskutowania oprogramowania oraz jego implikacji przed utworzeniem kodu.

Zalety TDD

Programowanie sterowane testami może tworzyć wysokiej jakości aplikacje w krótszym czasie niż jest to możliwe przy użyciu starszych metod. Pomyślne wdrożenie TDD wymaga od programistów i testerów dokładnego przewidzenia, w jaki sposób aplikacja i jej funkcjonalność będą wykorzystywane w świecie rzeczywistym.

TDD buduje zestaw testów regresji jako efekt uboczny, który może zminimalizować testy ręczne wykonywane przez ludzi, szybciej znajdując problemy, prowadząc do szybszych rozwiązań. Metodyczny charakter TDD zapewnia znacznie lepsze pokrycie i jakość za pierwszym razem niż klasyczne cykle kodu fazowego > test > naprawa > ponowne testowanie. Ponieważ testowanie jest przeprowadzane na wczesnym etapie cyklu projektowego, czas i pieniądze przeznaczone na późniejsze debugowanie są zminimalizowane.

Przewidywane zyski:

• znaczne zmniejszenie liczby defektów kosztem umiarkowanego wzrostu początkowego wysiłku rozwojowego
• koszty ogólne są więcej niż równoważone przez zmniejszenie nakładów pracy na końcowych etapach projektów
• TDD prowadzi do lepszej jakości projektu w kodzie i, bardziej ogólnie, wyższego stopnia „wewnętrznej” lub technicznej jakości, na przykład poprzez poprawę wskaźników spójności i sprzężenia

Wady TDD

TDD wymaga znacznych umiejętności, aby odnieść sukces, zwłaszcza na poziomie jednostki. Wiele starszych systemów po prostu nie jest tworzonych z myślą o testowaniu jednostkowym, co uniemożliwia izolowanie komponentów do testowania.

Ponadto wielu programistom brakuje umiejętności izolowania i tworzenia czystego kodu. Wszyscy członkowie zespołu muszą tworzyć i utrzymywać testy jednostkowe, w przeciwnym razie szybko staną się one przestarzałe. A organizacja patrząca na TDD będzie musiała zainwestować czas, zwolnić trochę teraz, aby później działać szybciej.

Wreszcie, jak w przypadku każdej metody, ostateczne wyniki TDD są tak dobre, jak użyte testy, dokładność ich wykonania oraz stopień, w jakim naśladują warunki, z jakimi spotykają się użytkownicy produktu końcowego.

Typowe błędy:

• zapominając o częstym przeprowadzaniu testów
• pisać zbyt wiele testów na raz
• pisać testy, które są zbyt duże lub obrzydliwe
• pisanie zbyt trywialnych testów, takich jak pomijanie twierdzeń
• pisać testy dla trywialnego kodu
• częściowa adopcja: tylko kilku programistów w grupie roboczej używa TDD
• słaba konserwacja zestawu testów, najczęściej prowadząca do zestawu testów o zbyt długim czasie wykonywania
• porzucony zestaw testów (tj. rzadko lub nigdy nie jest uruchamiany) – czasami z powodu złej konserwacji, czasami z powodu rotacji zespołu

Filozofia TDD

TDD pozwala programiście robić małe kroki podczas pisania oprogramowania. Test jest napisany przed przetestowaniem funkcjonalności i zapewnia, że ​​aplikacja nadaje się do testowalności. Testowanie na małej ilości kodu ma na celu wyłapanie błędów, które występują w testowanym kodzie. Następnie funkcjonalność jest realizowana. Nazywa się to „refaktorem czerwono-zielonym”, gdzie kolor czerwony oznacza niepowodzenie, a kolor zielony oznacza zaliczenie. Kroki te są następnie powtarzane. Pierwszym celem programisty jest skupienie się na zadaniu i pokonanie go.

Różne etapy cyklu rozwoju opartego na testach to:

• Dodaj test: Każda nowa funkcja w TDD zaczyna się od testu, który musi zakończyć się niepowodzeniem, ponieważ jest wprowadzany przed wdrożeniem jakiejkolwiek funkcji. Warunkiem wstępnym napisania testu przed wdrożeniem funkcjonalności jest jasne zrozumienie wymagań przez programistę. Osiąga się to poprzez historie użytkowników i przypadki użycia. Tak więc programista rozumie wymagania przed napisaniem kodu programu.
• Uruchom wszystkie testy i sprawdź, czy nowy kod się nie powiedzie: zapewnia to, że opaska testowa działa poprawnie i że nowy test nie zakończy się niepowodzeniem bez nowego kodu. Ten krok weryfikuje również test i eliminuje możliwość, że nowy test zawsze zakończy się pomyślnie.
• Napisz kod: Następnym krokiem jest napisanie kodu, który czyści test. Nowy kod nie jest doskonały, ale jest później modyfikowany zgodnie z wymaganiami. Został zaprojektowany po prostu do testowania i nie zawiera żadnych innych funkcji.
• Uruchom testy automatyczne: jeśli każdy wyprodukowany przypadek testowy z łatwością przejdzie test, oznacza to, że kod spełnia wszystkie wymagane specyfikacje. Następnie można rozpocząć ostatnią fazę cyklu.
• Refaktoryzacja kodu: jest podobna do usuwania duplikatów. Refaktoryzacja nie psuje żadnej istniejącej funkcjonalności i pomaga usunąć duplikaty między kodem produkcyjnym a testowym. Kod jest teraz czyszczony zgodnie z wymaganiami.
• Powtórz: Cykl powtarza się jak w poprzednich przypadkach z nowym testem. Podstawowym wymaganiem jest mały rozmiar kroku, z około 1-10 zmianami między każdym testem. Jeśli nowy kod nie przejdzie nowego testu, programista powinien przeprowadzić więcej debugowania. Ciągła integracja zapewnia odwracalne punkty kontrolne.

Ercole Palmeri