BDD (z anglického Behavior-Driven Development, česky vývoj řízený chováním) je agilní softwarová metodika, která rozšiřuje principy TDD (Test-Driven Development) o spolupráci mezi vývojáři, testery a obchodními zástupci (product owners). Cílem BDD je zajistit, že tým vyvíjí správnou funkcionalitu, která skutečně splňuje potřeby uživatelů a podnikání.

Na rozdíl od klasického testování, kde se testy píší až dodatečně, BDD začíná definicí požadovaného chování systému před samotným kódováním – a to v jazyce srozumitelném všem zúčastněným stranám.

BDD zformuloval Dan North v roce 2003 jako reakci na běžné problémy TDD:

• Testy psané pouze vývojáři často neodpovídají skutečným obchodním požadavkům.
• Nedostatek komunikace mezi technickým a netechnickým týmem.

Klíčové principy BDD:

• Společný jazyk – tým používá „doménový jazyk“ (Ubiquitous Language) pro popis požadavků.
• Příklady místo abstrakcí – chování se specifikuje pomocí konkrétních případů použití (scénářů).
• Automatizace specifikací – tyto příklady lze spustit jako živé testy.
• Zpětná vazba v reálném čase – okamžitě vidíme, zda systém chová podle očekávání.

BDD je tedy nadstavbou TDD, která přidává komunikační a specifikační vrstvu.

BDD využívá formální, ale člověkem čitelný jazyk Gherkin k popisu scénářů. Každý scénář má strukturu:

• Given – počáteční stav („předpoklady“),
• When – akce uživatele nebo událost,
• Then – očekávaný výsledek.

Příklad:

Scenario: User adds item to cart
  Given I am on the product page for "Notebook XYZ"
  When I click the "Add to Cart" button
  Then the cart should contain 1 item
  And I should see a confirmation message

Tyto scénáře se ukládají do souborů s příponou `.feature` a slouží jako živá dokumentace i jako spustitelné testy.

Nejznámějším nástrojem pro BDD je Cucumber, ale existují i alternativy:

Tyto nástroje mapují řádky Gherkinu na tzv. step definitions – funkce v programovacím jazyce, které skutečně provádějí test (např. ovládají webový prohlížeč přes Selenium).

• Lepší komunikace – odstraňuje nedorozumění mezi obchodní a technickou stránkou.
• Jasnější požadavky – chování je popsáno konkrétními příklady, ne vágními popisy.
• Živá dokumentace – `.feature` soubory jsou vždy aktuální, protože selhání testu signalizuje nesoulad.
• Rané odhalení chyb – chyby v pochopení požadavků se projeví hned při psaní scénářů.
• Automatizace akcepčních testů – snadná validace, že systém dělá to, co má.

• Náklady na zavádění – vyžaduje změnu myšlení a školení týmu.
• Nadměrná automatizace – BDD není vhodný pro všechny typy testů (např. jednotkové testy).
• Technické detaily v Gherkinu – pokud scénáře popisují „jak“ místo „co“, ztrácí se hlavní výhoda.
• Údržba testů – změna UI může vyžadovat úpravu mnoha step definitions.

• Začněte workshopy „Three Amigos“ – společné schůzky vývojáře, testera a product ownera k definici chování.
• Používejte přirozený jazyk – scénář by měl číst jako uživatelský příběh.
• Vyhněte se podmínkám a cyklům v `.feature` souborech – raději vytvořte samostatné scénáře.
• Nepřetěžujte Gherkin technickými detaily – ty patří do kódu, ne do specifikace.
• Integrujte BDD do CI/CD – automaticky spouštějte scénáře při každém commitu.

1. **Definice požadavku** – product owner popíše uživatelský příběh.
2. **Týmový workshop** – společně se vytvoří konkrétní příklady (scénáře v Gherkinu).
3. **Automatizace** – vývojář naimplementuje step definitions.
4. **Vývoj kódu** – vývojář píše kód tak, aby všechny scénáře prošly.
5. **Ověření** – tým společně ověří, že chování odpovídá očekávání.
6. **Refaktoring** – kód se upravuje, ale scénáře zůstávají stejné (zajišťují regresní bezpečnost).

• TDD
• Cucumber
• Gherkin
• Testování softwaru
• Agilní vývoj
• Uživatelský příběh
• Akcepční testování

• Dan North – „Introducing BDD“ (původní článek): https://dannorth.net/introducing-bdd/
• Oficiální Cucumber dokumentace: https://cucumber.io/docs/bdd/
• BDD v češtině – komunitní zdroje: https://www.agilecz.cz (vyhledávej „BDD“)

• Behavior-Driven Development – FAQ
• Živá dokumentace
• Testovací pyramidy
• CI/CD