tdd vs bdd analyze differences with examples
Ten samouczek wyjaśnia różnice między TDD a BDD z przykładami:
TDD lub Test Driven Development i BDD lub Behavior Driven Development to dwie techniki tworzenia oprogramowania.
Zanim zagłębimy się w różnicę między tymi dwoma, najpierw zrozumiemy, co one oznaczają indywidualnie i jak są używane?
Zaczynajmy!!
Czego się nauczysz:
Co to jest TDD?
TDD to skrót od Test Driven Development. W tej technice tworzenia oprogramowania najpierw tworzymy przypadki testowe, a następnie piszemy kod leżący u ich podstaw. Chociaż TDD jest techniką programistyczną, można ją również wykorzystać do tworzenia testów automatyzacji.
Zespoły, które wdrażają TDD, potrzebują więcej czasu na rozwój, jednak zwykle znajdują bardzo niewiele usterek. TDD skutkuje lepszą jakością kodu oraz kodem, który jest bardziej elastyczny i wielokrotnego użytku.
TDD pomaga również w osiągnięciu wysokiego pokrycie testu około 90-100%. Najtrudniejszą rzeczą dla programistów śledzących TDD jest napisanie przypadków testowych przed napisaniem kodu.
Sugerowany odczyt => Kompletny przewodnik do pisania doskonałych przypadków testowych
Proces TDD
Metodologia TDD opiera się na bardzo prostym 6-etapowym procesie:
1) Napisz przypadek testowy: W oparciu o wymagania napisz zautomatyzowany przypadek testowy.
2) Uruchom wszystkie przypadki testowe: Uruchom te automatyczne przypadki testowe na aktualnie opracowanym kodzie.
3) Opracuj kod dla tych przypadków testowych: Jeśli przypadek testowy się nie powiedzie, napisz kod, aby ten przypadek testowy działał zgodnie z oczekiwaniami.
4) Ponownie uruchom przypadki testowe: Ponownie uruchom przypadki testowe i sprawdź, czy wszystkie dotychczas opracowane przypadki testowe zostały zaimplementowane.
5) Refaktoryzuj swój kod: To opcjonalny krok. Jednak ważne jest, aby zreformować kod, aby był bardziej czytelny i można go było ponownie wykorzystać.
6) Powtórz kroki 1–5 dla nowych przypadków testowych: Powtarzaj ten cykl dla innych przypadków testowych, aż wszystkie przypadki testowe zostaną zaimplementowane.
Przykład implementacji przypadku testowego w TDD
Załóżmy, że wymagamy opracowania funkcji logowania dla aplikacji, która ma pola nazwy użytkownika i hasła oraz przycisk przesyłania.
Krok 1: Utwórz przypadek testowy.
@Test Public void checkLogin(){ LoginPage.enterUserName('UserName'); LoginPage.enterPassword('Password'); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }
Krok 2: Uruchom ten przypadek testowy, a pojawi się błąd informujący, że strona logowania nie jest zdefiniowana i nie ma metod o nazwach enterUserName, enterPassword i submit.
jak odtworzyć plik torrent
Krok 3: Opracuj kod dla tego przypadku testowego. Napiszmy podstawowy kod, który wprowadzi nazwę użytkownika i hasło i otrzyma obiekt strony głównej, gdy będą poprawne.
public class LoginPage{ String username; String password; //store username public void enterUserName(String username){ this.username = username; } //store password public void enterPassword(String password){ this.password = password; } //match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } } }
Krok 4: Uruchom ponownie przypadek testowy, a otrzymamy wystąpienie strony głównej.
Krok 5: Przebudujmy kod, aby wyświetlał prawidłowe komunikaty o błędach, gdy warunki if w metodzie przesyłania nie są prawdziwe.
//match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } else{ System.out.println('Please provide correct password'); return; } } else{ System.out.println('Please provide correct username'); }
Krok 6: Teraz napiszmy nowy przypadek testowy z pustą nazwą użytkownika i hasłem.
@Test Public void checkLogin(){ LoginPage.enterUserName(''); LoginPage.enterPassword(''); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }
Teraz, jeśli spróbujesz uruchomić ten przypadek testowy, zakończy się niepowodzeniem. Powtórz kroki od 1 do 5 dla tego przypadku testowego, a następnie dodaj funkcję obsługi pustych ciągów nazw użytkownika i haseł.
Co to jest BDD?
BDD to skrót od Behavior Driven Development. BDD jest rozszerzeniem TDD, w którym zamiast pisać przypadki testowe, zaczynamy od napisania zachowania. Później tworzymy kod, który jest wymagany, aby nasza aplikacja wykonywała dane zachowanie.
Scenariusz zdefiniowany w podejściu BDD ułatwia współpracę programistom, testerom i użytkownikom biznesowym.
BDD jest uważane za najlepszą praktykę, jeśli chodzi o testy automatyczne ponieważ skupia się na zachowaniu aplikacji, a nie na myśleniu o implementacji kodu.
Zachowanie aplikacji jest w centrum uwagi w BDD i zmusza programistów i testerów do wchodzenia w buty klienta.
Proces BDD
Proces związany z metodologią BDD również składa się z 6 kroków i jest bardzo podobny do procesu TDD.
1) Napisz zachowanie aplikacji: Zachowanie aplikacji jest napisane prostym językiem angielskim, takim jak język, przez właściciela produktu, analityków biznesowych lub pracowników kontroli jakości.
2) Napisz automatyczne skrypty: Ten prosty język podobny do angielskiego jest następnie konwertowany na testy programistyczne.
3) Zaimplementuj kod funkcjonalny: Następnie implementowany jest kod funkcjonalny będący podstawą zachowania.
4) Sprawdź, czy zachowanie się powiodło: Uruchom zachowanie i sprawdź, czy się powiodło. Jeśli się powiedzie, przejdź do następnego zachowania, w przeciwnym razie napraw błędy w kodzie funkcjonalnym, aby uzyskać zachowanie aplikacji.
5) Refaktoryzuj lub organizuj kod: Zmień lub zorganizuj kod, aby był bardziej czytelny i można go było ponownie wykorzystać.
6) Powtórz kroki 1-5 dla nowego zachowania: Powtórz kroki, aby zaimplementować więcej zachowań w aplikacji.
Przeczytaj także => Jak testerzy są zaangażowani w techniki TDD, BDD i ATDD
Przykład implementacji zachowania w BDD
Załóżmy, że wymagamy opracowania funkcji logowania dla aplikacji, która ma pola nazwy użytkownika i hasła oraz przycisk przesyłania.
Krok 1: Napisz zachowanie aplikacji przy wprowadzaniu nazwy użytkownika i hasła.
Scenario: Login check Given I am on the login page When I enter 'username' username And I enter 'Password' password And I click on the 'Login' button Then I am able to login successfully.
Krok 2: Napisz skrypt automatycznego testu dla tego zachowania, jak pokazano poniżej.
@RunWith(Cucumber.class) public class MyStepDefinitions { @Steps LoginPage loginPage; @Steps HomePage hp; @Given('^I am on the login page $') public void i_am_on_the_login_page(){ loginPage.gotoLoginPage(); } @When('^I enter '((^')*)' username$') public void i_enter_something_username(String username) { loginPage.enterUserName(username); } @When('^I enter '((^')*)' password$') public void i_enter_something_password(String password) { loginPage.enterPassword(password); } @When('^I click on the '((^')*)' button$') public void i_click_on_the_submit_button(String strArg1) { hp = loginPage.submit(); } @Then('^I am able to login successfully.$') public void i_am_able_to_login_successfully() { Assert.assertNotNull(hp); } }
Krok 3: Zaimplementuj kod funkcjonalny (jest to podobne do kodu funkcjonalnego w kroku 3 przykładu TDD).
public class LoginPage{ String username = ''; String password = ''; //store username public void enterUserName(String username){ this.username = username; } //store password public void enterPassword(String password){ this.password = password; } //match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } } }
Krok 4: Uruchom to zachowanie i sprawdź, czy się powiedzie. Jeśli się powiedzie, przejdź do kroku 5, w przeciwnym razie debuguj funkcjonalną implementację, a następnie uruchom ją ponownie.
Krok 5: Refaktoryzacja implementacji jest krokiem opcjonalnym iw tym przypadku możemy refaktoryzować kod w metodzie przesyłania, aby wydrukować komunikaty o błędach, jak pokazano w kroku 5 dla przykładu TDD.
//match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } else{ System.out.println('Please provide correct password'); return; } } else{ System.out.println('Please provide correct username'); }
Krok 6: Napisz inne zachowanie i wykonaj kroki od 1 do 5 dotyczące tego nowego zachowania.
Możemy napisać nowe zachowanie, aby sprawdzić, czy otrzymujemy błąd za niewprowadzenie nazwy użytkownika, jak pokazano poniżej:
Scenario: Login check Given I am on the login page And I click on the 'Login' button Then I get an error to enter username.
TDD Vs BDD - Kluczowe różnice
TDD | BDD |
---|---|
Może być lepszym podejściem do projektów, które obejmują API i narzędzia innych firm. | Może być lepszym podejściem do projektów, które są napędzane działaniami użytkowników. Na przykład: witryna e-commerce, system aplikacji itp. |
Oznacza rozwój oparty na testach. | Oznacza rozwój oparty na zachowaniu. |
Proces rozpoczyna się od napisania przypadku testowego. | Proces rozpoczyna się od napisania scenariusza zgodnie z oczekiwanym zachowaniem. |
TDD koncentruje się na sposobie implementacji tej funkcjonalności. | BDD koncentruje się na zachowaniu aplikacji dla użytkownika końcowego. |
Przypadki testowe są napisane w języku programowania. | Scenariusze są bardziej czytelne w porównaniu z TDD, ponieważ są napisane w prostym formacie angielskim. |
Zmiany w działaniu aplikacji mają duży wpływ na przypadki testowe w TDD. | Na scenariusze BDD nie mają większego wpływu zmiany funkcjonalności. |
Współpraca jest wymagana tylko między programistami. | Wymagana jest współpraca między wszystkimi interesariuszami. |
Niektóre z narzędzi obsługujących TDD to: JUnit, TestNG, NUnit itp. | Niektóre z narzędzi obsługujących BDD to SpecFlow, Cucumber, MSpec itp. |
Testy w TDD mogą być zrozumiane tylko przez osoby posiadające wiedzę programistyczną, | Testy w BDD mogą być zrozumiane przez każdą osobę, także osoby bez znajomości programowania. |
TDD zmniejsza prawdopodobieństwo wystąpienia błędów w testach. | Błędy w testach są trudne do śledzenia w porównaniu z TDD. |
Wniosek
Wybór między TDD a BDD może być bardzo trudny. Niektórzy mogą twierdzić, że BDD jest lepszy do znajdowania błędów, podczas gdy inni mogą po prostu powiedzieć, że TDD zapewnia większe pokrycie kodu.
Żadna metodologia nie jest lepsza od drugiej. Decyzja o wyborze metodyki zależy od osoby i zespołu projektowego.
Mamy nadzieję, że ten artykuł rozwiał Twoje wątpliwości dotyczące TDD vs BDD !!
rekomendowane lektury
- Ponad 180 przykładowych przypadków testowych aplikacji internetowych (przykładowa lista kontrolna)
- Jak przetłumaczyć ręczne przypadki testowe na skrypty automatyzacji? - Przewodnik krok po kroku z przykładem
- Pytania do wywiadu dotyczącego przypadków testowych: Napisz przypadki testowe na podstawie scenariusza
- W jaki sposób testerzy są zaangażowani w techniki TDD, BDD i ATDD
- Pokrycie testów w testowaniu oprogramowania (wskazówki dotyczące maksymalizacji pokrycia testowego)
- 8 Narzędzia i struktury testowe oparte na najlepszym zachowaniu (BDD)
- Samouczek Specflow: najlepszy przewodnik po narzędziu BDD
- Jak pisać przypadki testowe: najlepszy przewodnik z przykładami