Relacja między BDD a TDD

Jaki jest związek między BDD a TDD?

Z tego, co zrozumiałem, BDD dodaje dwie główne rzeczy w stosunku do TDD: nazewnictwo testów (zapewnij / powinieneś) i testy akceptacyjne. Czy powinienem stosować się do TDD podczas opracowywania przez BDD? Jeśli tak, to czy moje testy jednostek TDD powinny być nazywane w tym samym stylu?

BDD dodaje cykl wokół cyklu TDD.

Zaczynasz więc od zachowania i pozwól, aby kierowały nim testy, a następnie pozwól, by testy napędzały rozwój. Idealnie, BDD jest sterowany przez pewien rodzaj testu akceptacji, ale nie jest to w 100% konieczne. Tak długo, jak zdefiniujesz oczekiwane zachowanie, nic ci nie jest.

Powiedzmy, że piszesz stronę logowania.

Zacznij od szczęśliwej ścieżki:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

Ta składnia „biorąc pod uwagę, kiedy i kiedy”, jest powszechna w rozwoju opartym na zachowaniu. Jedną z jego zalet jest to, że mogą być czytane (i ze szkoleniem, pisane) przez osoby, które nie są programistami - to znaczy, że interesariusze mogą przeglądać listę zachowań, które zdefiniowałeś dla pomyślnego ukończenia zadania i sprawdzić, czy to odpowiada ich oczekiwaniom na długo przed wydaniem niekompletnego produktu.

Istnieje język skryptowy, znany jako Korniszon, który wygląda podobnie do powyższego i umożliwia pisanie kodu testowego za klauzulami w tych zachowaniach. Powinieneś poszukać tłumacza opartego na korniszonie dla swojego zwykłego środowiska programistycznego. To nie wchodzi w zakres tej odpowiedzi.

W każdym razie wracając do zachowania. Twoja bieżąca aplikacja jeszcze tego nie robi (jeśli tak, to dlaczego ktoś prosi o zmianę?), Więc test kończy się niepowodzeniem, niezależnie od tego, czy używasz testera, czy po prostu testujesz ręcznie.

Teraz nadszedł czas, aby przejść do cyklu TDD, aby zapewnić tę funkcjonalność.

Niezależnie od tego, czy piszesz BDD, czy nie, twoje testy powinny mieć wspólną składnię. Jedną z najczęstszych jest opisana przez ciebie składnia „powinna”.

Napisz test: ShouldAcceptValidDetails. Przejdź przez cykl Red-Green-Refactor, aż będziesz z niego zadowolony. Czy teraz przechodzimy test zachowania? Jeśli nie, napisz kolejny test: ShouldRedirectToUserDefaultPage. Red-Green-Refactor, aż będziesz szczęśliwy. Umyj, spłucz, powtarzaj, aż spełnisz kryteria określone w zachowaniu.

Następnie przechodzimy do następnego zachowania.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Teraz nie powinieneś był uprzedzać tego, aby przekazać swoje wcześniejsze zachowanie. W tym momencie powinieneś zaliczyć ten test. Wróć więc do swojego cyklu TDD.

I tak dalej, aż będziesz mieć swoją stronę.

Gorąco polecam The Rspec Book, aby dowiedzieć się więcej o BDD i TDD, nawet jeśli nie jesteś programistą Ruby.

Moje rozumienie tego:

• BDD zaczęło jako rebranding TDD, aby skupić się na zachowaniu.
• Daje to bardziej formalne wsparcie (DSL i oprzyrządowanie) dla skupienia się na zachowaniu i specyfikacjach wykonywalnych.
• BDD można teraz postrzegać jako nadzbiór TDD. Z czasem rozrósł się, aby objąć większą część wymagań związanych z pobieraniem rzeczy, ale nadal proces rozwoju jest jego zasadniczą częścią.

Aby zająć się TDD wykonaną właściwą częścią BDD. BDD zaczęło się od zmiany języka TDD, aby wyjaśnić intencję procesu. Artykuł wprowadzający Dana Northa na temat BDD wyjaśnia, dlaczego skupienie się na zachowaniu słów zamiast na testowaniu jest użyteczne - pomaga potwierdzić, że nie tylko tworzysz odpowiednie oprogramowanie, ale także tworzysz odpowiednie oprogramowanie. To zawsze było częścią dobrego podejścia TDD, ale Dan trochę go skodyfikował do BDD.

To, co myślę, BDD czyni nieco bardziej wyraźnym niż TDD, a przynajmniej formalizuje i zapewnia wsparcie dla narzędzia, to takie podejście dwuprzetworowe / podwójna pętla / powiększanie / pomniejszanie / zewnątrz. Najpierw opisujesz oczekiwane zachowanie funkcji (pętla zewnętrzna), a następnie przybliżasz ją do pętli wewnętrznej, aby poradzić sobie ze specyfikacjami niskiego poziomu.

Od http://www.metesreau.com/ncraft-workshop/

Korniszon w połączeniu z narzędziami takimi jak Cucumber i SpecFlow umożliwiają pisanie specyfikacji wysokiego poziomu funkcji, a następnie łączenie ich z kodem wykonującym kod aplikacji. Twierdziłbym, że w tym miejscu BDD może „czuć się” inaczej niż TDD, ale nadal robi to samo, tylko z pewną dodatkową obsługą narzędzi i DSL. Nieco bliżej „tradycyjnego” TDD jest używanie narzędzi takich jak rspec, nspec, spock. Czują się trochę bardziej jak w tradycyjnym TDD, ale z językiem bardziej skoncentrowanym na zachowaniu.

W BDD in Action autorstwa Johna Fergusona Smarta (wysoce zalecane) opowiada się za podejściem z podwójną pętlą, zaczynając od czegoś takiego jak jBehave na zewnętrznych specyfikacjach wykonywalnych na poziomie zewnętrznym, a następnie przechodząc do narzędzia takiego jak Spock dla specyfikacji niskiego poziomu.

BDD przybliża koncepcję testowania do interesariuszy biznesowych. Korniszon ma być czytelny dla biznesu, a idea „żywej dokumentacji”, tj. Automatycznie generowanych raportów postępu z twoich specyfikacji plików wykonywalnych, polega na przekazywaniu informacji zwrotnej interesariuszom.

Kolejną częścią BDD, w której rzeczywiście staje się czymś, co zawiera TDD jako część większego procesu, są bity i części wywołujące wymagania. Pomysły takie jak wprowadzanie funkcji, mapowanie wpływu i rzeczywiste opcje są częścią tej strony.

Aby uzyskać kanoniczną odpowiedź na to pytanie, lepiej może udać się ponownie do Dan North . Jeśli cały zespół jest programistami, to BDD = TDD. Jeśli twój zespół obejmuje cały szereg interesariuszy, BDD jest bliżej XP, a TDD jest jego częścią.

Jaki jest związek między BDD a TDD?

To są te same rzeczy.

Z tego, co zrozumiałem, BDD dodaje dwie główne rzeczy w stosunku do TDD: nazewnictwo testów (upewnij się / powinno)

To naprawdę nie jest coś, co BDD „dodaje”. To tylko inna konwencja, która ma ułatwić nauczanie i rozumienie TDD.

Wszyscy, którzy stworzyli BDD, uczyli TDD i zauważyli, że najtrudniej zrozumieć, że TDD nie ma absolutnie nic wspólnego z testowaniem. Gdy uczniowie przeszli przez tę przeszkodę, stało się im znacznie łatwiej. Ale bardzo trudno jest oderwać się od myślenia o testowaniu , gdy słowo „test” (lub powiązana terminologia, taka jak „twierdzić”) pojawia się praktycznie wszędzie . Więc zamienili kilka słów.

Ale to tylko słowa! Nie ma faktycznej różnicy między TDD a BDD.

i testy akceptacyjne.

Testy akceptacyjne są tak samo ważną częścią TDD, jak i BDD. Ponownie: nie ma różnicy między TDD a BDD: TDD wykonane poprawnie to BDD, BDD to TDD wykonane poprawnie.