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

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 sterowany testami zaczyna się od projektowania i rozwojuping Testy dla każdej, nawet najmniejszej funkcjonalności aplikacji. Framework TDD nakazuje programistom pisanie nowego kodu tylko wtedy, gdy test automatyczny zakończył się niepowodzeniem. Pozwala to uniknąć duplikacji kodu. Pełna nazwa TDD to TDD (Test-driven development).

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 sterowany testami to proces rozwojuping i uruchamianie automatycznych testów przed faktycznym rozwojem aplikacji. Stąd TDD, czasami nazywane 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ć.

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ć.

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ść.

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

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.

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

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

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

Wydajność:

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.

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:

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 ().

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.

Wyjście:

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

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ą poświęcić więcej czasu na pisanie przypadków testowych TDD, debugowanie i programowanie zajmują znacznie mniej czasuping nowe funkcje. Będziesz pisać czystszy, mniej skomplikowany kod.

FAQ