Definicja #
BDD (Behavior-Driven Development) to metodyka wytwarzania oprogramowania rozwijająca TDD (Test-Driven Development) o wymiar komunikacji i współpracy między biznesem a zespołem technicznym. Opracowana przez Dana Northa w 2006 roku jako odpowiedź na trudności z adopcją TDD.
Główna idea BDD: testy powinny opisywać zachowanie systemu z perspektywy użytkownika i biznesu — nie szczegóły implementacji. Zamiast "test_getUserById_returns200" mamy "Given a registered user, When they request their profile, Then the response contains user data".
Składnia Gherkin — język naturalny dla BDD:
- Feature — nazwa opisywanej funkcjonalności
- Scenario — jeden konkretny przypadek użycia
- Given — stan wyjściowy (kontekst, preconditions)
- When — akcja wykonywana przez użytkownika lub system
- Then — oczekiwany rezultat (assertions)
- And / But — łączenie kroków
Narzędzia BDD:
- Cucumber — najpopularniejszy framework BDD; dostępny dla Javy, JavaScript (Cypress/Cucumber), Ruby, C#
- SpecFlow — implementacja Cucumber dla .NET (C#)
- Behave — BDD dla Pythona
- JBehave — oryginalne narzędzie Dana Northa dla Javy
BDD promuje praktykę Three Amigos — spotkania biznesu, QA i developerów przed implementacją w celu uzgodnienia scenariuszy i kryteriów akceptacji.
Zastosowania #
BDD stosuje się do:
- Definiowania kryteriów akceptacji przed implementacją — scenariusze Gherkin jako żywa dokumentacja
- Komunikacji w projektach Agile — trzeci amigo (biznes + QA + dev) uzgadniają zachowanie przed sprintem
- Automatyzacji testów akceptacyjnych i E2E — Cucumber lub SpecFlow uruchamiają scenariusze Gherkin jako testy automatyczne
- Dokumentacji systemu — scenariusze BDD opisują zachowanie systemu w języku biznesowym i aktualizują się razem z kodem
- Onboardingu i wiedzy domenowej — nowe osoby w projekcie szybko rozumieją wymagania przez czytelne scenariusze
Ścieżka nauki #
BDD łączy umiejętności techniczne z komunikacją — cenne zarówno dla QA, jak i developerów.
Zacznij od:
- Składnia Gherkin — pisanie Feature files: Feature, Scenario, Given/When/Then; zasady dobrego scenariusza (jeden scenariusz = jedno zachowanie)
- Cucumber — instalacja, powiązanie kroków Gherkin z kodem (Step Definitions)
- Przykładowy stack: Cucumber + Java + Selenium lub Cucumber + JavaScript + Playwright
- Warsztaty Three Amigos — jak prowadzić spotkania wymagań z BDD
Następnie poznaj:
- SpecFlow (C#/.NET) lub Behave (Python) — jeśli to twój ekosystem
- Scenario Outline + Examples — parametryzacja scenariuszy dla wielu zestawów danych
- Integracja z CI/CD — raporty Allure lub Cucumber HTML Reports w Jenkins/GitLab
- Granice BDD — nie wszystko powinno być w Gherkin; testy jednostkowe nadal w JUnit/NUnit; BDD dla akceptacyjnych
FAQ #
- Czym różni się BDD od TDD?
- TDD (Test-Driven Development) to technika pisania testów jednostkowych przed kodem, skupiona na implementacji z perspektywy developera. BDD rozszerza TDD o język naturalny (Gherkin) i perspektywę biznesową/użytkownika. BDD ułatwia komunikację między rolami, TDD to technika implementacji kodu.
- Czy trzeba używać Cucumbera do BDD?
- Nie — BDD to podejście, nie narzędzie. Można stosować BDD bez Cucumbera, pisząc testy z dobrymi nazwami opisującymi zachowanie (Given-When-Then w komentarzach lub nazwach metod). Cucumber formalizuje to przez pliki .feature w Gherkin, co jest użyteczne gdy biznes czyta scenariusze.
- Czy BDD spowalnia zespół?
- Źle wdrożone BDD (zbyt duże pokrycie Gherkin, brak zaangażowania biznesu) może spowolnić. Prawidłowe BDD skupia się na scenariuszach akceptacyjnych i E2E — nie na testach jednostkowych. Three Amigos przyspiesza alignment i zmniejsza późniejsze nieporozumienia co do wymagań.
- Ile zarabia QA Engineer stosujący BDD?
- QA Automation Engineer ze znajomością BDD, Cucumber i Gherkin zarabia w Polsce od 9 000 do 18 000 zł brutto. BDD jest często wymagane w dojrzałych zespołach Agile — zwłaszcza gdy istnieje silna współpraca QA z biznesem.
