Co to jest programowanie sterowane testami (TDD)? Samouczek z przykładem

Spisie treści:

Anonim

Rozwój oparty na testach

Test Driven Development (TDD) to podejście do tworzenia oprogramowania, w którym przypadki testowe są opracowywane w celu określenia i sprawdzenia, co zrobi kod. Mówiąc prosto, przypadki testowe dla każdej funkcjonalności są tworzone i testowane jako pierwsze, a jeśli test się nie powiedzie, nowy kod jest zapisywany w celu przejścia testu i uczynienia kodu prostym i wolnym od błędów.

Programowanie sterowane testami rozpoczyna się od zaprojektowania i opracowania testów dla każdej małej funkcjonalności aplikacji. TDD instruuje programistów, aby pisali nowy kod tylko wtedy, gdy automatyczny test zakończy się niepowodzeniem. Pozwala to uniknąć powielania kodu. Pełna forma TDD to programowanie oparte na testach.

Prostą koncepcją TDD jest napisanie i poprawienie zakończonych niepowodzeniem 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 wymagania, które musimy przetestować, aby je spełnić).

Programowanie sterowane testami to proces tworzenia i uruchamiania testów automatycznych przed faktycznym opracowaniem aplikacji. Stąd TDD czasami nazywane również jako Test First Development.

W tym samouczku dowiesz się więcej o:

  • Jak przeprowadzić test TDD
  • TDD Vs. Tradycyjne testy
  • Co to jest akceptacja TDD i Developer TDD
  • Skalowanie TDD za pomocą Agile Model Driven Development (AMDD)
  • Test Driven Development (TDD) vs. Agile Model Driven Development (AMDD)
  • Przykład TDD
  • Korzyści z TDD

Jak przeprowadzić test TDD

Poniższe kroki określają, jak wykonać test TDD,

  1. Dodaj test.
  2. Uruchom wszystkie testy i zobacz, czy jakikolwiek nowy test się nie powiedzie.
  3. Napisz kod.
  4. Uruchom testy i refaktoryzuj kod.
  5. Powtarzać.

Cykl TDD definiuje

  1. Napisz test
  2. Zrób to.
  3. Zmień kod, aby był poprawny, np. Refaktoryzacja.
  4. Powtórz proces.

Kilka wyjaśnień na temat TDD:

  • TDD nie dotyczy ani „testowania”, ani „projektowania”.
  • TDD nie oznacza „napisz część testów, a następnie zbuduj system, który przejdzie testy”.
  • TDD nie oznacza „rób dużo testów”.

TDD Vs. Tradycyjne testy

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

  • W przypadku tradycyjnego testowania pomyślny test pozwala wykryć co najmniej jedną usterkę. To jest to samo, co TDD. Jeśli test się nie powiedzie, osiągnąłeś postęp, ponieważ wiesz, że musisz rozwiązać problem.
  • TDD zapewnia, że ​​Twój system faktycznie spełnia określone dla niego wymagania. Pomaga budować zaufanie do systemu.
  • W TDD większy nacisk kładzie się na kod produkcyjny, który weryfikuje, czy testowanie będzie działać poprawnie. W tradycyjnym testowaniu większy nacisk kładzie się na projektowanie przypadków testowych. Czy test wykaże prawidłowe / niewłaściwe wykonanie aplikacji w celu spełnienia wymagań.
  • W TDD uzyskujesz test pokrycia 100%. W przeciwieństwie do tradycyjnych testów testowany jest każdy wiersz kodu.
  • Połączenie zarówno tradycyjnego testowania, jak i TDD prowadzi do tego, że ważniejsze jest testowanie systemu niż jego doskonalenie.
  • W Agile Modeling (AM) powinieneś "testować w celu". Powinieneś wiedzieć, dlaczego coś testujesz i na jakim poziomie należy to sprawdzić.

Co to jest akceptacja TDD i Developer TDD

Istnieją dwa poziomy TDD

  1. TDD akceptacji (ATDD): Za pomocą ATDD piszesz pojedynczy test akceptacyjny. Ten test 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 Behavioral Driven Development (BDD).
  2. Developer TDD: Za pomocą Developer TDD piszesz pojedynczy test programisty, tj. Test jednostkowy, a następnie kod produkcyjny wystarczający do wykonania tego testu. Test jednostkowy skupia się na każdej małej funkcjonalności systemu. Deweloper TDD nazywa się po prostu TDD.

    Głównym celem ATDD i TDD jest określenie szczegółowych, wykonywalnych wymagań dla rozwiązania na zasadzie just in time (JIT). JIT oznacza branie pod uwagę tylko tych wymagań, które są potrzebne w systemie. Więc zwiększ wydajność.

Skalowanie TDD za pomocą Agile Model Driven Development (AMDD)

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

Dlatego AMDD używane do większych problemów.

Cykl życia AMDD.

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

Na powyższym rysunku każde pudełko reprezentuje czynność deweloperską.

Wizjonowanie to jeden z procesów TDD polegający na przewidywaniu / wyobrażaniu sobie testów, które zostaną przeprowadzone w pierwszym tygodniu projektu. Głównym celem przewidywania jest określenie zakresu systemu i architektury systemu. Wysokopoziomowe wymagania i modelowanie architektury są wykonywane w celu pomyślnego przewidywania.

Jest to proces, w którym nie jest wykonywana szczegółowa specyfikacja oprogramowania / systemu, ale badanie wymagań oprogramowania / systemu określa ogólną strategię projektu.

  1. Iteracja 0: przewidywanie

Istnieją dwie główne subaktywacje.

  1. Wstępne przewidywanie wymagań.

    Zidentyfikowanie wymagań wysokiego poziomu i zakresu systemu może zająć kilka dni. Głównym celem jest zbadanie modelu użycia, początkowego modelu domeny i modelu interfejsu użytkownika (UI).

  2. Wstępne wyobrażenia architektoniczne.

    Również identyfikacja architektury systemu zajmuje kilka dni. Pozwala na wyznaczenie technicznych kierunków projektu. Głównym celem jest zbadanie diagramów technologicznych, przepływu interfejsu użytkownika (UI), modeli domeny i przypadków zmian.

  1. Modelowanie iteracyjne:

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

  • Proces zwinny jest używany dla każdej iteracji, tj. Podczas każdej iteracji nowy element pracy będzie dodawany z priorytetem.
  • Pod uwagę zostaną wzięte pierwsze prace o wyższym priorytecie. Dodane elementy pracy można w dowolnym momencie zmienić priorytety lub usunąć ze stosu elementów.
  • Zespół omawia, w jaki sposób zamierzają zrealizować każde wymaganie. W tym celu wykorzystuje się modelowanie.
  • Analiza modelowania i projektowanie są wykonywane dla każdego wymagania, które będzie wdrażane w tej iteracji.
  1. Model szturmowy:

    Jest to również znane jako modelowanie 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 innego o modelowanie z nimi. Ta sesja modelowania zajmie około 5 do 10 minut. Gdzie członkowie zespołu zbierają się, aby dzielić się tablicą / papierem.
  • Badają problemy, dopóki nie znajdują głównej przyczyny problemu. W samą porę, jeśli jeden z członków zespołu zidentyfikuje problem, który chce rozwiązać, skorzysta z szybkiej pomocy innych członków zespołu.
  • Następnie inni członkowie grupy badają problem, a następnie wszyscy kontynuują, jak poprzednio. Nazywa się to również modelowaniem stojącym lub sesjami kontroli jakości klienta.
  1. Rozwój sterowany testami (TDD).
  • Promuje testowanie potwierdzające kodu aplikacji i szczegółową specyfikację.
  • Zarówno test akceptacyjny (szczegółowe wymagania), jak i testy deweloperskie (test jednostkowy) są danymi wejściowymi dla TDD.
  • TDD sprawia, że ​​kod jest prostszy i przejrzysty. Pozwala deweloperowi na utrzymanie mniejszej ilości dokumentacji.
  1. Opinie.
  • To jest opcjonalne. Obejmuje inspekcje kodu i przeglądy modeli.
  • Można to zrobić dla każdej iteracji lub dla całego projektu.
  • Jest to dobra opcja, aby wyrazić opinię na temat projektu.

Test Driven Development (TDD) vs. Agile Model Driven Development (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 w przypadku większych problemów
  • TDD promuje tworzenie kodu wysokiej jakości
  • AMDD promuje wysokiej jakości komunikację z interesariuszami i programistami.
  • TDD rozmawia z programistami
  • AMDD rozmawia z analitykiem biznesowym, interesariuszami i specjalistami od danych.
  • TDD nie jest zorientowany wizualnie
  • Wizualnie zorientowany na AMDD
  • TDD ma ograniczony zakres do prac nad oprogramowaniem
  • AMDD ma szeroki zakres obejmujący interesariuszy. Wymaga pracy nad wspólnym zrozumieniem
  • Obie wspierają rozwój ewolucyjny
 --------------------------------------------

Przykład TDD

W tym przykładzie zdefiniujemy hasło klasy. W przypadku tej klasy postaramy się spełnić następujące warunki.

Warunek akceptacji hasła:

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

Najpierw piszemy kod, który spełnia wszystkie powyższe wymagania.

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

Uruchomimy powyżej klasy TestPassword ();

Wyjście jest ZALICZONE, jak pokazano poniżej;

Dane wyjściowe :

Scenariusz 2 : Tutaj widzimy, że w metodzie TestPasswordLength () nie ma potrzeby tworzenia instancji klasy PasswordValidator. Instancja oznacza utworzenie obiektu klasy w celu odniesienia się do elementów członkowskich (zmiennych / metod) tej klasy.

Z kodu usuniemy klasę PasswordValidator pv = new PasswordValidator (). Możemy wywołać metodę isValid () bezpośrednio przez PasswordValidator. IsValid („Abc123”) . (Zobacz zdjęcie poniżej)

Więc dokonujemy refaktoryzacji (zmiany kodu) jak poniżej:

Scenariusz 3 : Po refaktoryzacji dane wyjściowe pokazują stan błędu (patrz ilustracja poniżej), jest to spowodowane usunięciem instancji. Nie ma więc odniesienia do niestatycznej metody isValid ().

Musimy więc zmienić tę metodę, dodając słowo „static” przed wartością logiczną jako public static boolean isValid (hasło typu String). Refaktoryzacja klasy PasswordValidator () w celu usunięcia powyższego błędu i zaliczenia testu.

Wynik:

Po wprowadzeniu zmian w klasie PassValidator (), jeśli uruchomimy test, wynik będzie PASSED, jak pokazano poniżej.

Zalety TDD

  • Wczesne powiadamianie o błędach.

    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 ponownie uruchamiać w dowolnym momencie.

  • 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 z jedną odpowiedzialnością, a nie monolitycznych procedur z wieloma obowiązkami. To sprawia, że ​​kod jest łatwiejszy do zrozumienia.
    • TDD wymusza również pisanie tylko kodu produkcyjnego, aby przejść testy w oparciu o wymagania użytkownika.
  • Zaufanie do refaktoryzacji
    • Jeśli dokonasz refaktoryzacji kodu, mogą wystąpić przerwy w kodzie. Tak więc mając zestaw testów automatycznych, możesz naprawić te przerwy przed wydaniem. Odpowiednie ostrzeżenie zostanie wyświetlone, jeśli podczas testów automatycznych zostaną znalezione przerwy.
    • Używanie TDD powinno skutkować szybszym, bardziej rozszerzalnym kodem z mniejszą liczbą błędów, które można zaktualizować przy minimalnym ryzyku.
  • Dobre do pracy zespołowej

    W przypadku braku członka zespołu inni członkowie zespołu mogą łatwo odebrać kod i pracować nad nim. Pomaga również 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. Jest to proces modyfikowania kodu w celu przejścia wcześniej zaprojektowanego testu.
  • Większy nacisk kładziony jest na kod produkcyjny, a nie projekt przypadków testowych.
  • Programowanie sterowane testami to proces modyfikowania kodu w celu przejścia wcześniej zaprojektowanego testu.
  • W inżynierii oprogramowania jest czasami nazywany „Najpierw testowanie rozwoju”.
  • TDD obejmuje refaktoryzację kodu, tj. Zmianę / dodanie pewnej ilości kodu do istniejącego kodu bez wpływu na zachowanie kodu.
  • TDD, gdy jest używany, kod staje się jaśniejszy i łatwiejszy do zrozumienia.

Ten artykuł jest autorstwa Kanchana Kulkarniego