BDD - Test Driven Development
Kiedy spojrzysz na jakiekolwiek odniesienie do Behavior Driven Development, zauważysz użycie zwrotów takich jak „BDD pochodzi z TDD”, „BDD i TDD”. Aby wiedzieć, jak powstało BDD, dlaczego mówi się, że wywodzi się z TDD i czym jest BDD i TDD, musisz mieć zrozumienie TDD.
Dlaczego testowanie?
Na początek przejdźmy do podstaw testowania. Celem testowania jest upewnienie się, że budowany system działa zgodnie z oczekiwaniami. Rozważmy następujący przykład.
Dlatego z doświadczenia nauczyliśmy się, że odkrycie usterki w momencie jej wprowadzenia i natychmiastowe jej naprawienie byłoby opłacalne. Dlatego też istnieje konieczność pisania przypadków testowych na każdym etapie tworzenia i testowania. Tego właśnie nauczyły nas nasze tradycyjne praktyki testowania, które często określa się jako wczesne testy.
To podejście do testowania jest określane jako podejście Test-Last, ponieważ testowanie jest wykonywane po zakończeniu etapu.
Wyzwania związane z podejściem testowym
Podejście Test-Last było stosowane przez dłuższy czas w projektach tworzenia oprogramowania. Jednak w rzeczywistości przy takim podejściu, ponieważ testowanie musi poczekać do zakończenia określonego etapu, często jest pomijane z powodu:
Opóźnienia w ukończeniu etapu.
Napięte harmonogramy.
Skoncentruj się na dostawie na czas, pomijając testy.
Co więcej, w podejściu Test-Last, testy jednostkowe, które mają być wykonywane przez programistów, są często pomijane. Różne znalezione powody są oparte na sposobie myślenia twórców -
Są programistami, a nie testerami.
Testowanie jest obowiązkiem testerów.
Są wydajne w kodowaniu, a ich kod nie zawiera błędów.
Skutkuje to -
Kompromis w zakresie jakości dostarczonego produktu.
Odpowiedzialność za jakość ponoszą tylko testerzy.
Wysokie koszty naprawy usterek, przesyłka pocztowa.
Brak możliwości uzyskania satysfakcji klienta, co oznaczałoby również utratę powtarzalnych transakcji, a tym samym wpływa na wiarygodność.
Te czynniki wymagały zmiany paradygmatu i skupienia się na testowaniu. Rezultatem było podejście Test-First.
Podejście najpierw test
Podejście Test-First zastępuje sposób programowania od wewnątrz (napisz kod, a następnie test) na zewnętrzny (napisz test, a następnie kod).
To podejście jest uwzględnione w następujących metodologiach tworzenia oprogramowania (które również są zwinne) -
miXtreme Programowanie (XP).
Test Drozdarty Drozwój (TDD).
W tych metodologiach deweloper projektuje i zapisuje testy jednostkowe dla modułu kodu przed napisaniem pojedynczego wiersza modułu kodu. Deweloper tworzy następnie moduł kodu w celu przejścia testu jednostkowego. Dlatego te metodologie wykorzystują testy jednostkowe do kierowania rozwojem.
Podstawową kwestią, aby zauważyć, że celem jest rozwój oparty na testowaniu.
Cykl czerwony-zielony-refaktor
Programowanie sterowane testami służy do tworzenia kodu na podstawie testów jednostkowych.
Step 1 - Rozważmy moduł kodu, który ma zostać napisany.
Step 2 - Napisz test
Step 3 - Uruchom test.
Test kończy się niepowodzeniem, ponieważ kod nadal nie jest napisany. Dlatego krok 2 jest zwykle określany jako napisanie testu, który zakończy się niepowodzeniem.
Step 4 - Napisz minimalny kod możliwy do zaliczenia testu.
Step 5- Przeprowadź wszystkie testy, aby upewnić się, że nadal kończą się powodzeniem. Testy jednostkowe są zautomatyzowane, aby ułatwić ten krok.
Step 6 - Refaktoryzacja.
Step 7 - Powtórz kroki od 1 do 6 dla następnego modułu kodu.
Każdy cykl powinien być bardzo krótki, a typowa godzina powinna zawierać wiele cykli.
Jest to również popularnie znane jako Red-Green-Refactor cykl, gdzie -
Red - Pisanie testu, który kończy się niepowodzeniem.
Green - Pisanie kodu do zaliczenia testu.
Refactor - Usuń powielanie i popraw kod do akceptowalnych standardów.
Kroki procesu TDD
Poniżej zilustrowano etapy procesu TDD.
Zalety TDD
Korzyści lub zalety programowania sterowanego testami:
Deweloper musi najpierw zrozumieć, jaki powinien być pożądany wynik i jak go przetestować przed utworzeniem kodu.
Kod komponentu jest zakończony tylko wtedy, gdy test zakończy się pomyślnie, a kod zostanie refaktoryzowany. Zapewnia to testowanie i refaktoryzację, zanim programista przejdzie do następnego testu.
Ponieważ zestaw testów jednostkowych jest uruchamiany po każdym refaktoryzacji, informacja zwrotna, że każdy składnik nadal działa, jest stała.
Testy jednostkowe działają jak żywa dokumentacja, która jest zawsze zgodna z danymi.
Jeśli zostanie znaleziona wada, programista tworzy test, aby ujawnić tę wadę, a następnie modyfikuje kod, tak aby test przeszedł pomyślnie, a defekt został naprawiony. Skraca to czas debugowania. Wszystkie inne testy również są uruchamiane, a po ich przejściu zapewnia to, że istniejąca funkcjonalność nie zostanie uszkodzona
Deweloper może w dowolnym momencie podejmować decyzje projektowe i dokonywać refaktoryzacji, a przeprowadzenie testów zapewnia, że system nadal działa. To sprawia, że oprogramowanie jest łatwe w utrzymaniu.
Deweloper ma pewność, że wprowadzi dowolną zmianę, ponieważ jeśli zmiana wpłynie na jakąkolwiek istniejącą funkcjonalność, to samo zostanie ujawnione przez uruchomienie testów, a usterki można natychmiast naprawić.
Przy każdym kolejnym uruchomieniu testowym weryfikowane są również wszystkie poprzednie poprawki defektów, a powtarzalność tego samego defektu jest ograniczona.
Ponieważ większość testów jest wykonywana podczas samego rozwoju, testowanie przed dostawą jest skrócone.
Wady TDD
Punktem wyjścia są User Stories, opisujące zachowanie systemu. Dlatego programiści często stają przed następującymi pytaniami -
Kiedy testować?
Co przetestować?
Jak sprawdzić, czy specyfikacja jest spełniona?
Czy kod zapewnia wartość biznesową?
Błędne przekonania na temat TDD
W branży istnieją następujące błędne przekonania, które wymagają wyjaśnienia.
| Nieporozumienie | Wyjaśnienie |
|---|---|
| TDD polega na testowaniu i automatyzacji testów. | TDD to metodologia programistyczna wykorzystująca podejście Test-First. |
| TDD nie obejmuje żadnego projektu. | TDD obejmuje krytyczną analizę i projektowanie w oparciu o wymagania. Projekt pojawia się podczas rozwoju. |
| TDD jest tylko na poziomie Jednostki. | TDD może być używany na poziomie integracji i systemu. |
| TDD nie może być używane przez tradycyjne projekty testowe. | TDD stał się popularny w programowaniu ekstremalnym i jest używany w innych metodologiach Agile. Można go jednak używać również w tradycyjnych projektach testowych. |
| TDD to narzędzie. | TDD jest metodologią programistyczną i po przejściu każdego nowego testu jednostkowego jest dodawany do pakietu Automation Test Suite, ponieważ wszystkie testy muszą być uruchamiane za każdym razem, gdy dodawany jest nowy kod lub modyfikowany jest istniejący kod, a także po każdej refaktoryzacji. Dlatego narzędzia do automatyzacji testów obsługujące TDD ułatwiają ten proces. |
| TDD oznacza przekazanie testów akceptacyjnych programistom. | TDD nie oznacza wręczania testów akceptacyjnych programistom. |
Akceptacja TDD
Acceptance Test Driven Development (ATDD) definiuje kryteria akceptacji i testy akceptacji podczas tworzenia historii użytkowników, na wczesnym etapie rozwoju. ATDD koncentruje się na komunikacji i wspólnym zrozumieniu między klientami, programistami i testerami.
Kluczowe praktyki w ATDD są następujące -
Omów rzeczywiste scenariusze, aby zbudować wspólne zrozumienie domeny.
Skorzystaj z tych scenariuszy, aby uzyskać kryteria akceptacji.
Zautomatyzuj testy akceptacyjne.
Skoncentruj rozwój na tych testach.
Użyj testów jako specyfikacji na żywo, aby ułatwić wprowadzenie zmian.
Korzyści z używania ATDD są następujące -
Wymagania są jednoznaczne i pozbawione luk funkcjonalnych.
Inni rozumieją specjalne przypadki, które przewidują programiści.
Testy akceptacji kierują rozwojem.
TDD Vs BDD
Według Dana Northa programiści zwykle napotykają następujące problemy podczas wykonywania programowania sterowanego testami -
Gdzie zacząć
Co testować, a czego nie
Ile przetestować za jednym razem
Jak nazwać ich testy
Jak zrozumieć, dlaczego test się nie udał
Rozwiązaniem wszystkich tych problemów jest rozwój oparty na zachowaniu. Wyewoluował z ustalonych praktyk zwinnych i został zaprojektowany, aby uczynić je bardziej dostępnymi i skutecznymi dla zespołów, jako nowość w zwinnym dostarczaniu oprogramowania. Z biegiem czasu BDD rozrosło się, aby objąć szerszy obraz zwinnej analizy i zautomatyzowanych testów akceptacyjnych.
Główny difference between TDD and BDD czy to -
TDD opisuje, jak działa oprogramowanie.
Z drugiej strony BDD -
Opisuje, w jaki sposób użytkownik końcowy korzysta z oprogramowania.
Sprzyja współpracy i komunikacji.
Podkreśla przykłady zachowań Systemu.
Celuje w wykonywalne specyfikacje zaczerpnięte z przykładów