Co to jest rozwój oparty na testach (TDD)? Przykład

Przez: Tomasza Hamiltona Tomasza Hamiltona
Hours Zaktualizowano

Co to jest rozwój oparty na testach (TDD)?

Rozwój oparty na testach (TDD) to podejście do tworzenia oprogramowania, w którym opracowywane są przypadki testowe w celu określenia i sprawdzenia działania kodu. Krótko mówiąc, najpierw tworzone i testowane są przypadki testowe dla każdej funkcjonalności, a jeśli test się nie powiedzie, pisany jest nowy kod, aby przejść test i uczynić kod prostym i wolnym od błędów.

Rozwój oparty na testach rozpoczyna się od zaprojektowania i opracowania testów dla każdej najmniejszej funkcjonalności aplikacji. Struktura TDD instruuje programistów, aby pisali nowy kod tylko wtedy, gdy automatyczny test nie powiódł się. Pozwala to uniknąć powielania kodu. Pełna forma TDD to rozwój oparty na testach.

Rozwój oparty na testach

Prostą koncepcją TDD jest napisanie i poprawienie nieudanych testów przed napisaniem nowego kodu (przed rozwojem). Pomaga to uniknąć powielania kodu, gdy piszemy niewielką ilość kodu na raz, aby przejść testy. (Testy to nic innego jak warunki wymagań, które musimy przetestować, aby je spełnić).

Rozwój oparty na testach to proces opracowywania i przeprowadzania automatycznych testów przed faktycznym rozwojem aplikacji. Dlatego TDD jest czasami nazywany także jako Przetestuj pierwszy rozwój.

Jak wykonać test TDD

Poniższe kroki definiują sposób przeprowadzania testu TDD:

  1. Dodaj test.
  2. Uruchom wszystkie testy i sprawdź, czy jakiś nowy test zakończy się niepowodzeniem.
  3. Napisz jakiś kod.
  4. Uruchom testy i refaktoryzuj kod.
  5. Powtarzać.
Wykonaj test TDD
Pięć kroków rozwoju opartego na testach

Cykl TDD definiuje

  1. Napisz test
  2. Spraw, żeby to działało.
  3. Zmień kod, aby był poprawny, tj. Refaktor.
  4. Powtórz proces.

Kilka wyjaśnień na temat TDD:

  • Podejście TDD nie polega ani na „testowaniu”, ani na „projektowaniu”.
  • TDD nie oznacza „napisz kilka testów, a następnie zbuduj system, który przejdzie testy.
  • TDD nie oznacza „wykonywania wielu testów”.

TDD vs. Tradycyjne testowanie

Poniżej znajduje się główna różnica między rozwojem opartym na testach a tradycyjnym testowaniem:

Podejście TDD jest przede wszystkim techniką specyfikacji. Zapewnia, że ​​kod źródłowy jest dokładnie testowany na poziomie potwierdzającym.

  • W przypadku tradycyjnych testów udany test pozwala wykryć jeden lub więcej defektów. To samo co TDD. Kiedy test się nie powiedzie, poczyniłeś postęp, ponieważ wiesz, że musisz rozwiązać problem.
  • TDD gwarantuje, że Twój system faktycznie spełnia określone dla niego wymagania. Pomaga zbudować pewność siebie w stosunku do posiadanego systemu.
  • W TDD większy nacisk kładzie się na kod produkcyjny, który sprawdza, czy testowanie będzie działać poprawnie. W testowaniu tradycyjnym większy nacisk kładzie się na projektowanie przypadków testowych. Czy test wykaże prawidłowe/nieprawidłowe wykonanie aplikacji w celu spełnienia wymagań.
  • W TDD osiągasz test pokrycia 100%. W przeciwieństwie do tradycyjnych testów testowana jest każda linia kodu.
  • Połączenie zarówno tradycyjnego testowania, jak i TDD prowadzi do tego, że ważniejsze jest testowanie systemu niż doskonalenie systemu.
  • In Modelowanie zwinne (AM)powinieneś „testować w określonym celu”. Powinieneś wiedzieć, dlaczego coś testujesz i na jakim poziomie należy to przetestować.

POWIĄZANE ARTYKUŁY

Co to jest TDD akceptacji i TDD dewelopera

Istnieją dwa poziomy TDD

  1. TDD akceptacji (ATDD): Za pomocą ATDD piszesz pojedynczy test akceptacyjny. Test ten spełnia wymagania specyfikacji lub potwierdza zachowanie systemu. Następnie napisz wystarczającą ilość kodu produkcyjnego/funkcjonalnego, aby spełnić ten test akceptacyjny. Test akceptacyjny koncentruje się na ogólnym zachowaniu systemu. ATDD był również znany jako Rozwój oparty na zachowaniu (BDD).
  2. TDD programisty: Dzięki Developer TDD piszesz test pojedynczego programisty, tj. test jednostkowy, a następnie kod produkcyjny wystarczający do wypełnienia tego testu. Test jednostkowy koncentruje się na każdej najmniejszej funkcjonalności systemu. Programista TDD nazywa się po prostu as TDD.Głównym celem ATDD i TDD jest określenie szczegółowych, wykonywalnych wymagań dla rozwiązania w trybie just in time (JIT). JIT oznacza uwzględnienie tylko tych wymagań, które są potrzebne w systemie. Zwiększ więc efektywność.

Akceptacja TDD i Developer TDD

Skalowanie TDD poprzez Agile Model Driven Development (AMDD)

TDD jest bardzo dobry w szczegółowej specyfikacji i walidacji. Nie udaje mu się przemyśleć większych kwestii, takich jak ogólny projekt, użycie systemu lub interfejs użytkownika. AMDD rozwiązuje problemy ze skalowaniem Agile, których TDD nie robi.

Dlatego AMDD zostało wykorzystane do większych problemów.

Cykl życia AMDD

Cykl życia AMDD

W rozwoju opartym na modelu (MDD) obszerne modele są tworzone przed napisaniem kodu źródłowego. Które z kolei mają zwinne podejście?

Na powyższym rysunku każde pole przedstawia czynność rozwojową.

Wizualizacja jest jednym z procesów TDD przewidywania/wyobrażania testów, które zostaną przeprowadzone w pierwszym tygodniu projektu. Głównym celem wizualizacji jest określenie zakresu systemu i architektury systemu. Wymagania wysokiego poziomu i modelowanie architektury są wykonywane w celu pomyślnej wizualizacji.

Jest to proces, podczas którego nie dokonuje się szczegółowej specyfikacji oprogramowania/systemu, ale badanie wymagań oprogramowania/systemu, które określa ogólną strategię projektu.

Iteracja 0: Przewidywanie

Istnieją dwie główne subaktywacje.

  1. Wstępne przewidywanie wymagań.Określenie wymagań wysokiego poziomu i zakresu systemu może zająć kilka dni. Główny nacisk położony jest na zbadanie modelu użytkowania, początkowego modelu domeny i modelu interfejsu użytkownika (UI).
  2. Początkowy Archiwyobrażenia techniczne. Identyfikacja architektury systemu zajmuje również kilka dni. Pozwala to na ustalenie kierunków technicznych dla projektu. Głównym celem jest eksploracja diagramów technologicznych, przepływu interfejsu użytkownika (UI), modeli domen i przypadków zmian.

Modelowanie iteracyjne

Tutaj zespół musi zaplanować pracę, która zostanie wykonana w każdej iteracji.

  • W każdej iteracji stosowany jest proces zwinny, tzn. podczas każdej iteracji nowy element pracy będzie dodawany z priorytetem.
  • Pod uwagę zostaną wzięte w pierwszej kolejności prace o wyższym priorytecie. Dodanym elementom pracy można w dowolnym momencie zmienić priorytety lub je usunąć ze stosu elementów.
  • Zespół omawia sposób wdrożenia każdego wymagania. W tym celu stosuje się modelowanie.
  • Analiza modelowania i projektowanie są wykonywane dla każdego wymagania, które ma zostać zaimplementowane w tej iteracji.

Modelowy szturm

Nazywa się to również modelowaniem just in time.

  • Tutaj sesja modelowania obejmuje zespół 2/3 członków, którzy omawiają problemy na papierze lub tablicy.
  • Jeden członek zespołu poprosi drugiego, aby modelował z nim. Ta sesja modelowania zajmie około 5 do 10 minut. Miejsce, w którym członkowie zespołu zbierają się, aby dzielić się tablicą/papierem.
  • Badają problemy, dopóki nie znajdą głównej przyczyny problemu. W samą porę, jeśli jeden z członków zespołu zidentyfikuje problem, który chce rozwiązać, szybko skorzysta z pomocy pozostałych członków zespołu.
  • Następnie pozostali członkowie grupy badają tę kwestię, a następnie wszyscy kontynuują pracę jak poprzednio. Nazywa się to również modelowaniem na stojąco lub sesjami kontroli jakości klienta.

Rozwój oparty na testach (TDD)

  • Umożliwia przeprowadzenie testów potwierdzających kod aplikacji i szczegółową specyfikację.
  • Zarówno test akceptacyjny (wymagania szczegółowe), jak i testy programistyczne (test jednostkowy) stanowią dane wejściowe dla TDD.
  • TDD sprawia, że ​​kod jest prostszy i przejrzysty. Pozwala programiście na utrzymanie mniejszej ilości dokumentacji.

Recenzje

  • Jest to opcjonalne. Obejmuje inspekcje kodu i przeglądy modeli.
  • Można to zrobić dla każdej iteracji lub dla całego projektu.
  • Jest to dobra możliwość przekazania opinii na temat projektu.

Rozwój oparty na testach (TDD) vs. Rozwój oparty na modelu zwinnym (AMDD)

TDD AMDD
TDD skraca pętlę sprzężenia zwrotnego programowania AMDD skraca pętlę sprzężenia zwrotnego modelowania.
TDD to szczegółowa specyfikacja AMDD działa na większe problemy
TDD promuje tworzenie wysokiej jakości kodu AMDD stawia na wysoką jakość komunikacji z interesariuszami i deweloperami.
TDD rozmawia z programistami AMDD rozmawia z Analitycy Biznesowi, interesariuszy i specjalistów ds. danych.
TDD nie zorientowane wizualnie AMDD zorientowane wizualnie
TDD ma ograniczony zakres prac nad oprogramowaniem AMDD ma szeroki zakres, włączając zainteresowane strony. Wymaga to pracy nad wspólnym zrozumieniem
Obydwa wspierają rozwój ewolucyjny ---------------

Ramy TDD

Oto lista najlepszych frameworków do programowania sterowanego testami (TDD).

  1. Junita
  2. TestNG
  3. csUnit i NUnit
  4. Rspec

Teraz nauczmy się programowania opartego na testach na przykładzie.

Przykład TDD

Tutaj w tym przykładzie Test Driven Development zdefiniujemy hasło klasy. Dla tej klasy spróbujemy spełnić następujące warunki.

Warunek akceptacji Hasła:

  • Hasło powinno mieć od 5 do 10 znaków.

Najpierw w tym przykładzie TDD piszemy kod spełniający wszystkie powyższe wymagania.

Przykład TDD

Scenariusz 1: Aby uruchomić test, tworzymy klasę PasswordValidator ();

Przykład TDD

Będziemy działać powyżej klasy TestPassword ();

Dane wyjściowe są PASSED, jak pokazano poniżej;

Wydajność:

Przykład TDD

Scenariusz 2: Tutaj widzimy, że w metodzie TestPasswordLength () nie ma potrzeby tworzenia instancji klasy PasswordValidator. Instancja oznacza utworzenie przedmiot klasy, aby odwoływać się do elementów (zmiennych/metod) tej klasy.

Przykład TDD

Usuniemy z kodu klasę PasswordValidator pv = new PasswordValidator (). Możemy zadzwonić do jest ważna () metoda bezpośrednio przez Walidator hasła. Jest ważny („Abc123”). (Patrz obrazek poniżej)

Więc refaktoryzujemy (zmieniamy kod), jak poniżej:

Przykład TDD

Scenariusz 3:Po refaktoryzacji wyjście pokazuje status nieudany (patrz poniższy obrazek), ponieważ usunęliśmy instancję. Nie ma więc odniesienia do metody niestatycznej jest ważna ().

Przykład TDD

Musimy więc zmienić tę metodę, dodając słowo „static” przed wartością Boolean jako publiczną statyczną wartość logiczną isValid (hasło tekstowe). Refaktoryzacja klasy PasswordValidator (), aby usunąć powyższy błąd i przejść test.

Przykład TDD

Wyjście:

Jeśli po wprowadzeniu zmian w klasie PassValidator () uruchomimy test, wynik zostanie PASSED, jak pokazano poniżej.

Przykład TDD

Zalety TDD

Oto główne zalety programowania sterowanego testami (TDD) w inżynierii oprogramowania:

Wczesne powiadomienie o błędzie.

  • Programiści testują swój kod, ale w świecie baz danych często składa się to z testów ręcznych lub jednorazowych skryptów. Korzystając z TDD, z czasem tworzysz zestaw automatycznych testów, które Ty i każdy inny programista możecie dowolnie uruchamiać.

Lepiej zaprojektowany, czystszy i bardziej rozszerzalny kod.

  • Pomaga zrozumieć, w jaki sposób kod będzie używany i jak współdziała z innymi modułami.
  • Skutkuje to lepszą decyzją projektową i łatwiejszym w utrzymaniu kodu.
  • TDD umożliwia pisanie mniejszego kodu mającego jedną odpowiedzialność, zamiast monolitycznych procedur z wieloma obowiązkami. Dzięki temu kod jest łatwiejszy do zrozumienia.
  • TDD wymusza również pisanie wyłącznie kodu produkcyjnego, aby przejść testy w oparciu o wymagania użytkownika.

Zaufanie do refaktoryzacji

  • Jeśli refaktoryzujesz kod, mogą wystąpić przerwy w kodzie. Mając zestaw automatycznych testów, możesz naprawić te błędy przed wydaniem. W przypadku wykrycia przerw w stosowaniu testów automatycznych zostanie udzielone odpowiednie ostrzeżenie.
  • Korzystanie z TDD powinno skutkować szybszym, bardziej rozszerzalnym kodem z mniejszą liczbą błędów, który można zaktualizować przy minimalnym ryzyku.

Dobre do pracy zespołowej

  • W przypadku nieobecności któregokolwiek członka zespołu, pozostali członkowie zespołu mogą z łatwością zająć się kodem i pracować nad nim. Pomaga także w dzieleniu się wiedzą, zwiększając w ten sposób ogólną efektywność zespołu.

Dobre dla programistów

  • Chociaż programiści muszą spędzać więcej czasu na pisaniu przypadków testowych TDD, debugowanie i opracowywanie nowych funkcji zajmuje znacznie mniej czasu. Napiszesz czystszy, mniej skomplikowany kod.

Podsumowanie

  • TDD oznacza rozwój oparty na testach.
  • Znaczenie TDD: Jest to proces modyfikacji kodu w celu przejścia zaprojektowanego wcześniej testu.
  • Większy nacisk kładzie się na kod produkcyjny niż na projekt przypadku testowego.
  • Rozwój oparty na testach to proces modyfikowania kodu w celu zdania wcześniej zaprojektowanego testu.
  • In Inżynieria oprogramowania, Czasami nazywa się to „Najpierw przetestuj rozwój”.
  • Testowanie TDD obejmuje refaktoryzację kodu, tj. zmianę/dodanie pewnej ilości kodu do istniejącego kodu bez wpływu na zachowanie kodu.
  • Programowanie TDD, gdy jest używane, kod staje się wyraźniejszy i prostszy do zrozumienia.

Możesz lubić: