Jakie są podstawowe różnice między TDD i BDD?

głosy
119

Test Driven Development została wściekłość w społeczności .NET dla ostatnich kilku lat. Ostatnio słyszałem narzekania w ALT.NET społeczności o BDD. Co to jest? Co sprawia, że ​​różni się od TDD?

Utwórz 05/08/2008 o 16:58
źródło użytkownik
W innych językach...                            


15 odpowiedzi

głosy
94

I rozumie się bardziej BDD o specyfikacji niż testów . Jest ona związana z Domain Driven Design (nie kochasz te * DD akronimy?).

Jest ona związana z pewnym sposobem pisać historie użytkowników, w tym testów na wysokim szczeblu. Przykładem przez Toma dziesięć 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 idzie bezpośrednio do wykonania niniejszej specyfikacji testowej w Ruby).

Papież BDD jest Dan Północna . Znajdziesz wspaniałe wprowadzenie w jego Przedstawiamy BDD artykułu.

Znajdziesz tu porównanie BDD i TDD w tym filmie . Także opinia o BDD jako „TDD zrobić prawo” przez Jeremy D. Miller

25 marca 2013 Aktualizacja

Wideo powyżej zaginął na chwilę. O to ostatnie jeden za Llewellyn Falco BDD vs TDD (jak opisano) . I znaleźć jego wyjaśnienie jasno i na temat.

Odpowiedział 05/08/2008 o 17:36
źródło użytkownik

głosy
17

Dla mnie Podstawowa różnica między BDD i TDD jest ostrość i sformułowanie. Słowa są ważne dla komunikacji swoją intencję.

TDD kieruje skupić się na testowaniu. A ponieważ w „starej wodospad świata” testy przyjść po wdrożeniu, to sposób myślenia prowadzi do niewłaściwego zrozumienia i zachowania.

BDD kieruje skupić się na zachowaniu i specyfikacji, a więc wodospad umysły są rozproszony. BDD więc łatwiej jest rozumiane jako praktyki projektowej, a nie, jak w praktyce badawczej.

Odpowiedział 08/09/2008 o 19:36
źródło użytkownik

głosy
13

Wydaje się, że dwa rodzaje BDD.

Pierwszym z nich jest oryginalny styl, który Dan Północna omawia i co spowodowało utworzenie ram stylu xBehave. Dla mnie ten styl to przede wszystkim zastosowanie do testów akceptacyjnych lub specyfikacji przeciwko obiektów domeny.

Drugi styl to co Dave Astels spopularyzował i co do mnie, to nowa forma TDD, który ma kilka poważnych zalet. Koncentruje się ona na zachowanie, a nie testów, a także małych grupach testowych, próbując dostać się do punktu, w którym w zasadzie mają jedną linię za metody specyfikacji (test). Ten styl pasuje do wszystkich poziomów testów i może być wykonana przy użyciu dowolnego istniejące ramy testów jednostkowych chociaż nowe ramy (styl xSpec) pomagają skupić jedno zachowanie, a nie testów.

Istnieje również grupa BDD, które mogą okazać się przydatne:

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

Odpowiedział 10/09/2008 o 17:00
źródło użytkownik

głosy
6

Ja eksperymentowałem trochę z podejściem BDD i mój wniosek jest taki, że przedwczesne BDD doskonale nadaje się do wykorzystania realizację przypadku, ale nie na szczegółach bazowych. TDD nadal kołysać się na tym poziomie.

BDD jest również wykorzystywany jako narzędzie komunikacji. Celem jest, aby napisać specyfikację wykonywalne, które mogą być zrozumiane przez ekspertów w tej dziedzinie.

Odpowiedział 27/08/2008 o 21:59
źródło użytkownik

głosy
5

Test-Driven Development to metodologia tworzenia oprogramowania testowego pierwszy, co oznacza, że nie wymaga pisania kodu testowego przed napisaniem rzeczywisty kod, który zostanie przetestowany. Słownie Kenta Becka:

Styl jest tutaj napisać kilka linijek kodu, a następnie test, który powinien działać, albo jeszcze lepiej, aby napisać test, który nie będzie działał, a następnie napisać kod, który pozwoli go uruchomić.

Po dowiedzieć się, jak napisać jeden mały kawałek kodu, teraz, a nie tylko na kodowanie, chcemy uzyskać natychmiastową informację zwrotną i praktykę „code trochę przetestować trochę, trochę kodu, testowania trochę.” Więc od razu napisać test dla niego.

TDD jest tak niskim poziomie, że metodologia techniczny programistów używa do produkcji czystego kodu, który działa.

Zachowanie-Driven Development to metodologia, która została stworzona w oparciu o TDD, ale przekształciła się w procesie, który nie dotyczy tylko programistów i testerów, lecz dotyczy całego zespołu i wszystkich ważnych interesariuszy, technicznych i nietechnicznych. BDD zaczęło się od kilku prostych pytań, które TDD nie dobrze odpowiedzieć: ile testy mam napisać? Co mam faktycznie przetestować, a co nie? Które z testów piszę będzie w rzeczywistości ważnym dla firmy lub do ogólnej jakości produktu, a które są tylko moje over-engineering?

Jak widać, te pytania wymagają współpracy między technologią a biznesem. Przedsiębiorców oraz ekspertów domen często można powiedzieć inżynierom jaki rodzaj badań brzmią jak byłyby testy użyteczne, ale tylko wtedy, gdy badania są na wysokim poziomie, które dotyczą ważnych aspektów biznesowych. BDD wywołuje takie testy business-like „przykłady”, jak w „powiedz mi przykład, jak ta funkcja powinna zachowywać się poprawnie” i zastrzega sobie słowo „test” na niskim poziomie, kontrole techniczne, takie jak sprawdzanie poprawności danych lub integracji testowania API. Ważnym elementem jest to, że podczas badania mogą być tworzone tylko przez programistów i testerów, przykładami mogą być gromadzone i analizowane przez cały dostawy Team-projektantów, analityków, i tak dalej.

W zdaniu, jeden z najlepszych definicji BDD Mam znalezionych do tej pory jest to, że BDD jest o „konieczności rozmowy z ekspertami domeny i za pomocą przykładów, aby uzyskać wspólne rozumienie pożądanego zachowania i odkryć niewiadomych.” Część odkrycie jest bardzo ważne , Jako zespół dostawy zbiera więcej przykładów, zaczynają rozumieć domena biznes coraz bardziej, a tym samym zmniejszają ich niepewność co do niektórych aspektów tego produktu mają do czynienia. Ponieważ zmniejsza niepewność, kreatywność i autonomia wzrostu zespołowej dostawy. Na przykład, mogą teraz zacząć sugerując własne przykłady, że użytkownicy biznesowi nie myśleć były możliwe ze względu na brak wiedzy tech.

Teraz, po rozmowach z biznesem i domeny ekspertów brzmi świetnie, ale wszyscy wiemy, jak to często kończy się w praktyce. Zacząłem moją podróż z tech jako programista. Jako programiści, jesteśmy nauczeni napisać kod -algorithms, wzorce projektowe, abstrakcje. Lub, jeśli jesteś projektantem, to uczy się projektowania-organize informacji i tworzenie pięknych interfejsów. Ale gdy mamy nasze miejsca pracy entry-level, nasi pracodawcy oczekują od nas „dostarczanie wartości dla klientów.” A wśród tych klientów może być, na przykład ... banku. Ale mogę wiedzieć nic o bankowości z wyjątkiem, jak skutecznie zmniejszyć stan konta. Więc będę musiał jakoś tłumaczyć czego się ode mnie oczekuje w kodzie ... musiałbym zbudować most pomiędzy bankowością i mojej wiedzy technicznej, jeśli chcę, aby dostarczyć dowolną wartość. BDD pomaga mi budować taki most na stabilnym fundamencie płynnej komunikacji między zespołem dostawy i ekspertów w tej dziedzinie.

Ucz się więcej

Jeśli chcesz dowiedzieć się więcej o BDD, napisałem książkę na ten temat. „Pisanie Wielkiej Specyfikacje” zgłębia sztukę analizy wymagań i pomoże Ci dowiedzieć się, jak zbudować wielki proces BDD i korzystania z przykładów jako część rdzenia tego procesu. Książka opowiada o języku wszechobecnego, zbieranie przykładów i tworzenie tzw specyfikacji wykonywalny (zautomatyzowane testy) z przykładów-technik, które pomagają zespołom BDD dostarczyć wielką softeware na czas iw ramach budżetu.

Jeśli jesteś zainteresowany kupnem „Pisanie Wielkiej Specyfikacje” można zaoszczędzić 39% z kodem promocyjnym 39nicieja2 :)

Odpowiedział 12/02/2017 o 16:43
źródło użytkownik

głosy
2

Rozważmy Podstawową zaletą TDD być projekt. Należy zwany test Driven Design. BDD jest podzbiorem TDD nazwać Behavior Driven Design.

Rozważmy teraz popularną wdrażania TDD - testy jednostkowe. Jednostki w Unit Testing są zazwyczaj jeden bit logiki, która jest najmniejszą jednostką pracy można zrobić.

Po umieszczeniu tych jednostek ze sobą w sposób funkcjonalny do opisania pożądanego zachowania się maszyny, trzeba zrozumieć zachowanie jesteś opisujące maszyny. Zachowanie Driven Design skupia się na sprawdzeniu wiedzy realizatorów z przypadków użycia / Wymagania / cokolwiek i weryfikuje realizację poszczególnych funkcji. BDD i TDD w ogóle służy ważnemu celowi informowania projektowania i drugiego celu weryfikacji poprawności wykonania szczególnie gdy zmienia. BDD zrobione dobrze wiąże biz i dev (i QA), natomiast Unit Testing (być może błędnie postrzegane jako TDD zamiast jednego typu TDD) jest zazwyczaj odbywa się w silosie dev.

Dodam, że testy BDD służyć jako wymogami życia.

Odpowiedział 28/05/2015 o 22:36
źródło użytkownik

głosy
2

BDD jest w dużej mierze TDD zrobione dobrze. Jednakże, istnieje dodatkowa wartość, która oferuje BDD. Oto link na ten temat:

BDD jest więcej niż „TDD zrobione dobrze”

Odpowiedział 29/07/2010 o 11:25
źródło użytkownik

głosy
2

Z mojej najnowszej wiedzy w BDD w porównaniu do TDD, BDD skupia się na określenie, co będzie dalej, natomiast TDD skupia się na utworzenie zestawu warunków, a następnie patrząc na wyjściu.

Odpowiedział 25/05/2009 o 05:09
źródło użytkownik

głosy
2

Wydaje mi się, że BDD ma szerszy zakres. Oznacza to prawie TDD jest używany, że BDD jest metodologia encompasing który gromadzi informacje i wymagania dotyczące korzystania, amongh innymi praktyki TDD w celu zapewnienia szybkiej informacji zwrotnej.

Odpowiedział 05/08/2008 o 17:11
źródło użytkownik

głosy
2

Zachowanie Driven Development wydaje się bardziej skupić się na interakcji i komunikacji między twórcami a także między programistów i testerów.

Artykuł Wikipedii ma wyjaśnienie:

Rozwój zachowanie napędzane

Nie praktykuje BDD się jednak.

Odpowiedział 05/08/2008 o 17:06
źródło użytkownik

głosy
1

Różnica pomiędzy rozwojem testu napędzany (TDD) i rozwoju zachowań mechanicznych (BDD)

  • BDD skupia się na behawioralnego aspektu systemu aniżeli
    aspekcie wdrażania systemu, który koncentruje się na TDD.

  • BDD daje lepsze zrozumienie, co system powinien zrobić
    z punktu widzenia dewelopera i klienta. TDD tylko
    daje deweloperowi zrozumienie tego, co system powinien zrobić.

  • BDD umożliwia zarówno deweloperem i klientem pracować wspólnie na analizie wymagań, który jest zawarty w kodzie źródłowym systemu.

Odpowiedział 09/06/2017 o 23:49
źródło użytkownik

głosy
1

Oto szybka migawka:

  • TDD jest tylko proces testowania kodu przed zapisaniem go!

  • DDD to proces został poinformowany o domenie przed każdym cyklem kod dotykania!

  • BDD jest implementacją TDD, które przynosi w niektórych aspektach DDD!

Nadzieję, że pomoże!

Odpowiedział 18/01/2016 o 03:01
źródło użytkownik

głosy
0

Wybór między TDD i BDD jest skomplikowana. To zależy od tego, czy jest to właściwe ramy badania dla danego języka docelowego, co twoi współpracownicy są wygodne, a czasem innych czynników.

Niektórzy twierdzą, że BDD jest zawsze lepsze niż TDD, ponieważ ma możliwość wyeliminowania problemów, które mogą wystąpić podczas korzystania z TDD.

Kluczem do BDD jest to, że może to zapobiec problemom; to nie jest gwarantowane. Kwestie takie jak złą organizację kodu, złych praktyk projektowych, itd. Nadal będzie się utrzymywać. Musisz po prostu mieć niższy prawdopodobny kaptur pisanie złych testy, a tym samym mają bardziej rozbudowane funkcje.

Odpowiedział 18/09/2016 o 09:59
źródło użytkownik

głosy
0

Nie ma różnicy betwen TDD i BDD. z wyjątkiem można przeczytać twoje testy lepsze, i można ich używać jako wymagania. Jeśli piszesz swoje wymagania z tymi samymi słowami jak piszesz testy BDD następnie można przyjść Frome klienta z niektórych swoich badań określonych gotowy do pisania kodu.

Odpowiedział 07/10/2014 o 09:52
źródło użytkownik

głosy
-1

Ten blog stanowi interesujący punkt widzenia na różnice między TDD, BDD i ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/

Odpowiedział 20/05/2014 o 19:32
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more