====== BDD (Behavior-Driven Development) ======

**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.

===== Původ a principy =====

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í.

===== Rozdíl mezi TDD, ATDD a BDD =====

^ Metodika | Zaměření | Hlavní aktéři | Forma specifikace ^
| **TDD** (Test-Driven Development) | Jednotkové testy, nízkoúrovňová logika | Vývojáři | Kód (např. JUnit, pytest) |
| **ATDD** (Acceptance Test-Driven Development) | Akcepční kritéria, shoda na požadavcích | Vývojáři, testeři, product owner | Tabulky, příklady |
| **BDD** | Chování systému z pohledu uživatele | Celý tým (včetně netechnických členů) | Přirozený jazyk (Gherkin) |

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

===== Gherkin – jazyk pro popis chování =====

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:
<code gherkin>
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
</code>

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

===== Nástroje pro BDD =====

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

| Jazyk       | Nástroj           | Poznámka |
|-------------|-------------------|----------|
| Java        | Cucumber-JVM      | Nejrozšířenější implementace |
| JavaScript  | @cucumber/cucumber, Playwright + Gherkin | Podpora pro moderní E2E testování |
| .NET (C#)   | SpecFlow          | Plně integrován do Visual Studia |
| Python      | behave, pytest-bdd| behave je nejbližší Cucumberu |
| Ruby        | Cucumber          | Původní implementace |

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).

===== Výhody BDD =====

  * **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á.

===== Nevýhody a rizika =====

  * **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.

===== Doporučené postupy (Best Practices) =====

  * **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.

===== BDD v praxi – typický workflow =====

  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).

===== Související pojmy =====

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

===== Externí odkazy =====

  * 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“)

===== Viz také =====

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