Behavior-Driven Development (BDD) to metodyka wytwarzania oprogramowania, w której funkcjonalności opisujesz przez zachowanie systemu widziane oczami użytkownika. Podejście stworzył Dan North około 2003 roku jako rozwinięcie Test-Driven Development (TDD). Zamiast pytać, czy kod działa poprawnie na poziomie jednostki, BDD pyta, jak system ma się zachować w konkretnej sytuacji biznesowej i zapisuje to językiem zrozumiałym dla całego zespołu.

Sednem jest wspólny słownik projektu (ubiquitous language). Analityk, programista i tester używają tych samych pojęć w tym samym znaczeniu, więc opis wymagania nie rozjeżdża się między dokumentem a implementacją. Dzięki temu ograniczasz ryzyko, że gotowa funkcja rozminie się z oczekiwaniami po odbiorze.

Format Given-When-Then i język Gherkin

Scenariusze BDD zapisujesz w składni Gherkin, opartej na trzech krokach:

• Given – stan wyjściowy przed akcją, na przykład zalogowany użytkownik z pustym koszykiem;
• When – akcja wykonywana przez użytkownika, na przykład dodanie produktu do koszyka;
• Then – oczekiwany rezultat, na przykład aktualizacja liczby pozycji i sumy zamówienia.

Taki zapis czyta się jak zdanie w języku naturalnym, a jednocześnie da się go podpiąć pod kod i uruchomić jako wykonywalny test akceptacyjny. Jeden scenariusz pełni więc podwójną funkcję: opisuje wymaganie i sprawdza, czy zostało spełnione. To rozwiązuje typowy problem dokumentacji, która dezaktualizuje się szybciej, niż ktokolwiek zdąży ją przeczytać.

Elementy pracy w BDD

Proces BDD spina kilka powtarzalnych elementów:

• Historie użytkownika (User Story) opisujące wartość biznesową z perspektywy odbiorcy;
• scenariusze będące konkretnymi przykładami zachowań dla danej historii;
• automatyzację, czyli przełożenie kroków Gherkina na kod testowy;
• wspólne warsztaty wymagań z udziałem interesariuszy, na których uzgadniacie przykłady, zanim powstanie kod.

Narzędzia BDD

Najpopularniejszym narzędziem jest Cucumber, który obsługuje wiele języków programowania i głęboko integruje się z systemami CI. Dla platformy .NET stosowano SpecFlow, obecnie zastąpiony przez Reqnroll. W ekosystemie znajdziesz też JBehave, Behat, Behave oraz Gauge. Wybór zależy od stosu technologicznego zespołu, bo scenariusze Gherkina pozostają w dużej mierze przenośne między narzędziami. Praktyczny przegląd samego podejścia znajdziesz w What is Behavior-Driven Development (BDD)? – CircleCI oraz w opracowaniu Behavior-driven development – Wikipedia (EN).

BDD a TDD – różnice i współistnienie

BDD i TDD często mylone są jako alternatywy, choć działają na różnych poziomach. TDD skupia się na poprawności kodu na poziomie jednostkowym, BDD opisuje zachowanie systemu i akceptację biznesową na poziomie funkcjonalnym. W praktyce zespoły łączą oba: TDD pilnuje jakości implementacji, a BDD dba o zgodność z wymaganiami. Porównania z konkretnymi przykładami znajdziesz w BDD vs TDD – Cucumber.io Blog i w artykule TDD vs. BDD: What’s the Difference? – Semaphore CI.

BDD sprawdza się w zespołach Scrum oraz w środowiskach DevOps, gdzie liczy się szybka i powtarzalna weryfikacja zgodności oprogramowania z potrzebami biznesu. Zastosowanie nie kończy się na wymaganiach funkcjonalnych – scenariuszami możesz opisywać także wymagania niefunkcjonalne, na przykład wydajnościowe zgodne ze standardem ISO/IEC/IEEE 25010.

Korzyści i warunki skuteczności

Badania nad wdrożeniami BDD (m.in. Santos et al., 2024) wskazują na lepszą współpracę zespołową i wyższą jakość oprogramowania. Efekt nie pojawia się jednak sam. Scenariusze trzeba utrzymywać jako aktualną dokumentację, a wszystkie role muszą realnie angażować się w ich tworzenie. Zestaw nieaktualnych, nikomu niepotrzebnych plików Gherkina to dodatkowy koszt bez zwrotu.

FAQ

Czym różni się BDD od TDD?

TDD dotyczy jakości kodu na poziomie testów jednostkowych, a BDD opisuje zachowanie systemu i akceptację biznesową na poziomie funkcjonalnym. Oba podejścia można stosować równolegle w jednym projekcie.

Czy do BDD potrzebuję Cucumbera?

Nie zawsze. Cucumber jest najpopularniejszy, ale dla .NET używasz Reqnroll (dawniej SpecFlow), a w innych ekosystemach JBehave, Behat, Behave lub Gauge. Sam sposób pisania scenariuszy w Gherkinie jest wspólny dla tych narzędzi.

Kto powinien pisać scenariusze Given-When-Then?

Najlepsze efekty daje wspólne pisanie na warsztatach z udziałem osoby po stronie biznesu, programisty i testera. Uzgodnienie przykładów przed kodowaniem redukuje niedoprecyzowane wymagania.