Redakcja
Dan North, który ukuł to pojęcie próbuje w swojej pracy na nowo zdefiniować testy jednostkowe pisane zgodnie z metodą TDD (Test-Driven Development), dodać do tego testy akceptacyjne (UAT - User Acceptance Test) i ostatecznie połączyć je w jedno (nierozumiane bezpośrednio), tworząc BDD. Podstawą tej metody jest próba możliwie najpełniejszego poznania potrzeb, celów i oczekiwań klienta oraz wytworzenie oprogramowania spełniającego te założenia.
Testy akceptacyjne opierają się w niej zazwyczaj o historyjki (user stories) pisane w następującym formacie:
"Jako [rola]..., chcę [funkcja]..., by [korzyść]..." (ang. As a..., I want..., so that...)
Kryterium akceptacji dla historyjki przybiera formę:
"Zakładając, że..., jeśli..., to (wtedy)..." (ang. Given..., when..., then...).
Dan North wyjaśnia jak rozumieć BDD, gdzie słówko "test" zostaje zastąpione przez słówko "zachowanie" (ang. behavior). Liz Keogh dodaje, że BDD uzupełnia lukę dla "powinno". Wiadomym jest, że wymagania są w wielu przypadkach niejednoznaczne, a musimy je opisywać w sposób zero-jedynkowy - albo coś ma się wydarzyć, albo nie. Dzięki temu możemy zdefiniować jednoznacznie weryfikowalny przypadek testowy. Czasami jednak musimy wyeksplorować obszary niejednoznaczne, stąd też pojęcie "zachowania" często odwołującego się do kontekstu użycia aplikacji przez użytkownika.
Całościowo BDD ma na celu zbudowanie właściwego oprogramowania w pierwszej próbie. Oczywiście jest to nie do osiągnięcia, ale na końcu na pewno będzie mniej poprawek - komentuje Janet Gregory.
Narzędzia stosowane w BDD:
- JBehave dla języka Java,
- RSpec (Cucumber) dla Ruby.
Dan North wyjaśnia BDD [EN]: http://www.viddler.com/v/c54123a
Gojko Adzic - BDD: Busting the myths from NDCOslo on Vimeo.
Źródła:
