Jakie są podstawowe różnice między TDD a BDD? [Zamknięte]

Rozwój oparty na testach jest modny w społeczności .NET od kilku lat. Ostatnio w społeczności ALT.NET słyszałem narzekania na temat BDD. Co to jest? Czym różni się od TDD?

Rozumiem, że BDD bardziej dotyczy specyfikacji niż testowania . Jest powiązany z Domain Driven Design (czy nie lubisz tych akronimów * DD?).

Jest to związane z pewnym sposobem pisania historyjek użytkownika, w tym testów wysokopoziomowych. Przykład autorstwa Toma ten Thij :

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

(W swoim artykule Tom przechodzi do bezpośredniego wykonania specyfikacji testu w Rubim).

Papieżem BDD jest Dan North . Znajdziesz świetne wprowadzenie w jego artykule wprowadzającym BDD .

W tym filmie znajdziesz porównanie BDD i TDD . Także opinia Jeremy'ego D. Millera o BDD jako „TDD zrobione dobrze”

Aktualizacja z 25 marca 2013 r

Powyższego wideo brakowało przez jakiś czas. Oto ostatnia wiadomość autorstwa Llewellyn Falco, BDD vs TDD (wyjaśnione) . Uważam, że jego wyjaśnienie jest jasne i na temat.

Dla mnie podstawową różnicą między BDD a TDD jest fokus i sformułowanie. A słowa są ważne, aby przekazać swoje zamiary.

TDD koncentruje się na testowaniu. A ponieważ w „starym świecie wodospadów” testy następują po wdrożeniu, to takie nastawienie prowadzi do niewłaściwego zrozumienia i zachowania.

BDD koncentruje się na zachowaniu i specyfikacji, więc umysły wodospadu są rozproszone. Zatem BDD jest łatwiejsze do zrozumienia jako praktyka projektowa, a nie praktyka testowania.

Wydaje się, że istnieją dwa rodzaje BDD.

Pierwszym z nich jest oryginalny styl, który omawia Dan North i który spowodował powstanie frameworków w stylu xBehave. Według mnie ten styl ma zastosowanie przede wszystkim do testów akceptacyjnych lub specyfikacji obiektów domeny.

Drugi styl jest tym, co spopularyzował Dave Astels i który dla mnie jest nową formą TDD, która ma poważne zalety. Skupia się na zachowaniu, a nie na testowaniu, a także na małych klasach testowych, próbując dojść do punktu, w którym w zasadzie masz jedną linię na metodę specyfikacji (test). Ten styl pasuje do wszystkich poziomów testowania i można go wykonać przy użyciu dowolnego istniejącego środowiska testów jednostkowych, chociaż nowsze struktury (styl xSpec) pomagają skupić się na zachowaniu, a nie na testowaniu.

Istnieje również grupa BDD, która może Ci się przydać:

http://groups.google.com/group/behaviordrivendevelopment/

Programowanie sterowane testami to metodologia tworzenia oprogramowania polegająca na testowaniu najpierw, co oznacza, że ​​wymaga napisania kodu testowego przed napisaniem rzeczywistego kodu, który będzie testowany. Słowami Kenta Becka:

Styl polega na napisaniu kilku wierszy kodu, następnie wykonaniu testu, a nawet lepiej napisaniu testu, który nie zostanie uruchomiony, a następnie napisaniu kodu, który go uruchomi.

Po zastanowieniu się, jak napisać jeden mały fragment kodu, zamiast tylko kodować, chcemy uzyskać natychmiastową informację zwrotną i poćwiczyć „koduj trochę, trochę testuj, koduj trochę, testuj trochę”. Dlatego od razu piszemy dla niego test.

Zatem TDD to niskopoziomowa metodologia techniczna, której programiści używają do tworzenia czystego kodu, który działa.

Behavior-Driven Development to metodologia, która została stworzona w oparciu o TDD, ale przekształciła się w proces, który nie dotyczy tylko programistów i testerów, ale dotyczy całego zespołu i wszystkich ważnych interesariuszy, technicznych i nietechnicznych. BDD zaczęło od kilku prostych pytań, na które TDD nie odpowiada: ile testów powinienem napisać? Co właściwie powinienem przetestować, a czego nie? Który z testów, które napiszę, będzie w rzeczywistości ważny dla firmy lub dla ogólnej jakości produktu, a które są po prostu moim przeprojektowaniem?

Jak widać, takie pytania wymagają współpracy między technologią a biznesem. Interesariusze biznesowi i eksperci dziedzinowi często mogą powiedzieć inżynierom, jakiego rodzaju testy brzmią tak, jakby byłyby przydatne - ale tylko wtedy, gdy są to testy wysokiego poziomu, które dotyczą ważnych aspektów biznesowych. BDD nazywa takie testy biznesowe „przykładami”, na przykład „powiedz mi przykład, jak ta funkcja powinna działać poprawnie”, a słowo „test” zastrzega dla niskopoziomowych testów technicznych, takich jak sprawdzanie poprawności danych lub testowanie integracji API. Ważną częścią jest to, że chociaż testy mogą być tworzone tylko przez programistów i testerów, przykłady mogą być zbierane i analizowane przez cały zespół dostarczający - przez projektantów, analityków i tak dalej.

W jednym zdaniu jedną z najlepszych definicji BDD, jakie do tej pory znalazłem , jest to, że BDD polega na „prowadzeniu rozmów z ekspertami w danej dziedzinie i używaniu przykładów w celu uzyskania wspólnego zrozumienia pożądanego zachowania i odkrywania nieznanych”. Część odkrywcza jest bardzo ważna. W miarę jak zespół dostarczający zbiera więcej przykładów, zaczyna coraz lepiej rozumieć domenę biznesową, a tym samym zmniejsza swoją niepewność co do niektórych aspektów produktu, z którym ma do czynienia. Wraz ze spadkiem niepewności wzrasta kreatywność i autonomia zespołu wykonawczego. Na przykład mogą teraz zacząć sugerować własne przykłady, których użytkownicy biznesowi nie uważali za możliwe z powodu braku wiedzy technicznej.

Teraz rozmowy z ekspertami biznesowymi i dziedzinowymi brzmią świetnie, ale wszyscy wiemy, jak często kończy się to w praktyce. Swoją przygodę z technologią rozpocząłem jako programista. Jako programiści uczymy się pisać kod - algorytmy, wzorce projektowe, abstrakcje. Lub, jeśli jesteś projektantem, uczysz się projektowania—Organizuj informacje i twórz atrakcyjne interfejsy. Ale kiedy otrzymujemy pracę na poziomie podstawowym, nasi pracodawcy oczekują od nas „dostarczania wartości klientom”. A wśród tych klientów może być np. ... bank. Ale nie mogłem wiedzieć prawie nic o bankowości - poza tym, jak skutecznie zmniejszyć saldo konta. Musiałbym więc jakoś przetłumaczyć to, czego się ode mnie oczekuje, na kod ... Musiałbym zbudować pomost między bankowością a moją wiedzą techniczną, jeśli chcę wnieść jakąkolwiek wartość. BDD pomaga mi zbudować taki most na stabilnym fundamencie płynnej komunikacji między zespołem dostarczającym a ekspertami dziedzinowymi.

Ucz się więcej

Jeśli chcesz poczytać więcej o BDD, napisałem książkę na ten temat. „Pisanie doskonałych specyfikacji” bada sztukę analizowania wymagań i pomoże ci nauczyć się budować wspaniały proces BDD i wykorzystywać przykłady jako podstawową część tego procesu. Książka omawia wszechobecny język, zbiera przykłady i tworzy z przykładów tak zwane specyfikacje wykonywalne (testy automatyczne) - techniki, które pomagają zespołom BDD dostarczać świetne oprogramowanie na czas i w ramach budżetu.

Jeśli jesteś zainteresowany kupnem „Pisania świetnych specyfikacji” , możesz zaoszczędzić 39% dzięki kodowi promocyjnemu 39nicieja2 :)

Poeksperymentowałem trochę z podejściem BDD i mój przedwczesny wniosek jest taki, że BDD dobrze nadaje się do implementacji przypadków użycia, ale nie dotyczy podstawowych szczegółów. TDD wciąż rządzi na tym poziomie.

BDD jest również używane jako narzędzie komunikacji. Celem jest napisanie wykonywalnych specyfikacji, które będą zrozumiałe dla ekspertów w tej dziedzinie.

Wydaje mi się, że BDD to szerszy zakres. To prawie sugeruje, że zastosowano TDD, że BDD jest obejmującą metodologią, która gromadzi informacje i wymagania dotyczące stosowania, między innymi, praktyk TDD w celu zapewnienia szybkiej informacji zwrotnej.

Z moją najnowszą wiedzą na temat BDD w porównaniu z TDD, BDD koncentruje się na określaniu, co będzie dalej, podczas gdy TDD skupia się na ustawieniu zestawu warunków, a następnie na spojrzeniu na wynik.

Rozwój oparty na zachowaniu wydaje się bardziej koncentrować na interakcji i komunikacji między programistami, a także między programistami a testerami.

Artykuł w Wikipedii zawiera wyjaśnienie:

Rozwój oparty na zachowaniu

Sam nie praktykuję BDD.

Rozważ podstawową korzyść TDD jako projekt. Powinien nazywać się Projekt oparty na testach. BDD jest podzbiorem TDD, nazwij to Projekt oparty na zachowaniu.

Rozważmy teraz popularną implementację TDD - testy jednostkowe. Jednostki w testach jednostkowych to zazwyczaj jeden bit logiki, który jest najmniejszą jednostką pracy, jaką możesz wykonać.

Kiedy łączysz te Jednostki w funkcjonalny sposób, aby opisać maszynom pożądane Zachowanie, musisz zrozumieć Zachowanie, które opisujesz maszynie. Projektowanie oparte na zachowaniu koncentruje się na weryfikacji zrozumienia przez wdrażających przypadków użycia / wymagań / cokolwiek i weryfikuje implementację każdej funkcji. Zasadniczo BDD i TDD służą istotnemu celowi informacyjnemu projektowi, a drugiemu celowi weryfikacji poprawności implementacji, zwłaszcza gdy się zmienia. BDD wykonane dobrze obejmuje biz i dev (i qa), podczas gdy testy jednostkowe (prawdopodobnie błędnie postrzegane jako TDD, a nie jeden typ TDD) są zwykle wykonywane w silosie deweloperskim.

Dodam, że testy BDD służą jako wymagania życiowe.

BDD jest w dużej mierze dobrze wykonanym TDD. Jest jednak dodatkowa wartość, którą oferuje BDD. Oto link do tego:

BDD to coś więcej niż „dobra robota TDD”

Nie ma różnicy między TDD i BDD. z wyjątkiem tego, że możesz lepiej czytać swoje testy i możesz ich używać jako wymagań. Jeśli piszesz swoje wymagania tymi samymi słowami, jak piszesz testy BDD, możesz pochodzić od klienta z niektórymi zdefiniowanymi testami gotowymi do napisania kodu.

Różnica między rozwojem opartym na testach (TDD) a rozwojem opartym na zachowaniu (BDD)

• BDD koncentruje się na behawioralnym aspekcie systemu, a nie na
  aspekcie implementacyjnym systemu, na którym koncentruje się TDD.

• BDD pozwala lepiej zrozumieć, co system powinien robić
  z perspektywy dewelopera i klienta. TDD
  daje tylko programistom zrozumienie tego, co powinien robić system.

• BDD umożliwia zarówno deweloperowi, jak i klientowi wspólną pracę nad analizą wymagań zawartą w kodzie źródłowym systemu.

Krótko mówiąc, istnieje duża różnica między TDD i BDD. W TDD koncentrujemy się głównie na danych testowych W BDD skupiamy się głównie na zachowaniu projektu, tak aby każda osoba nie programująca mogła zrozumieć wiersz kodu w imieniu tytułu ta metoda

Oto krótka migawka:

• TDD to tylko proces testowania kodu przed jego napisaniem!

• DDD to proces otrzymywania informacji o Domenie przed każdym cyklem dotykania kodu!

• BDD to implementacja TDD, która wprowadza pewne aspekty DDD!