Relacja między BDD a TDD

30

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?

SiberianGuy
źródło
1
BDD to zestaw dobrze udokumentowanych TDD (Unitests)
DD
Czy ktoś chciałby dodać odpowiedź z obozu Behaviour Driven Design ? Z mojego punktu widzenia te odpowiedzi dotyczą kilku pierwszych iteracji BDD. Udane zastosowania BDD w dzisiejszych czasach są często bliższe zaprojektowaniu , a nawet mogą całkowicie pominąć automatyczne testowanie, w razie potrzeby.
Paul Hicks
Różnica między BDD a TDD jest jak różnica między makroekonomią a mikroekonomią. BDD = budowanie zrozumienia wymagań na podstawie przykładów i opcjonalnie może być wykorzystane do przeprowadzenia automatycznych testów makr. (agilenoir.biz/en/am-i-behavioral-or-not), TDD = pisanie mikrotestów do kierowania pisaniem kodu. Podcast Agile Thoughts obejmuje również te różnice: agilenoir.biz/en/agilethoughts/test-automation-pyramid-series
Lance Kind

Odpowiedzi:

37

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.

pdr
źródło
Czy możesz po prostu dodać komentarz? Nadal nie rozumiem ...
Kochanie,
4

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.

Doubleloop TDD 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ą.

ngm
źródło
2

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.

Jörg W Mittag
źródło
W jaki sposób testy akceptacyjne są ważną częścią TDD?
SiberianGuy
@Idsa: są ważne, ponieważ Twój kod nie powinien przejść testów, które Twoim zdaniem powinny przejść, ale tych, które powinien wykonać kod. Myślę, że zbyt wielu ludzi jest zdezorientowanych tym, że większość testów jednostkowych odbywa się na niskim poziomie, dzięki czemu można uniknąć trudnego problemu z testowaniem tego, co system napisał ogólnie.
gbjbaanb
@Idsa: Oczywiście w ten sam sposób, w jaki są ważne dla BDD, ponieważ oba są tym samym ! Testy akceptacyjne sterują zewnętrznym cyklem TDD, tym dotyczącym funkcji i użytkowników, w przeciwieństwie do bardziej szczegółowego cyklu wewnętrznego, który dotyczy interfejsów API i protokołów i tym podobnych. Myślę, że Kent Beck nazywa to „Zoom In / Zoom Out”. Możesz na przykład łatwo to zobaczyć w pakiecie testowym JUnit, który zawiera prawdopodobnie co najmniej tyle testów akceptacyjnych, ile zawiera testy jednostkowe.
Jörg W Mittag
Testy akceptacyjne są ważną częścią TDD i BDD. Ale stwierdzenie, że BDD równa się TDD, jest podobne do powiedzenia, że ​​TDD równa się testowi pierwszemu. O ile nie zezwalasz na testowanie kodu, nie robisz TDD (znałem kogoś, kto chętnie pisałby testy z góry, ale argumentowałem, że kod powinien być zawsze napisany tak, jak by to było, gdybyś nie pisał jednostki testy i testy powinny być odpowiednio napisane). Podobnie, chyba że zezwalasz na zachowanie, aby przeprowadzić testy, nie robisz BDD.
pdr
1
@Isa: Zauważ, że istnieje wiele błędnych opisów TDD, które nie obejmują testów akceptacyjnych. Te - niestety dość popularne i powszechnie nauczane - złe opisy są jednym z powodów, dla których ludzie BDD uważali, że dobrym pomysłem może być zmiana marki TDD pod inną nazwą, aby uniknąć nieporozumień. Niemniej jednak i nie można tego powtarzać wystarczająco często, TDD i BDD są dokładnie tym samym .
Jörg W Mittag