BDD: Od komunikačního mostu k inženýrskému lešení
Stalo se vám někdy, že váš tým doručil software, který prošel všemi unit testy, vypadal technicky skvěle, ale po nasazení zákazník zjistil, že dělá něco úplně jiného, než potřeboval? Pokud ano, narazili jste na nejčastější problém moderního vývoje: propast mezi byznysovým zadáním a technickou implementací.
Právě tuto propast pomáhá překlenout Behavior-Driven Development (BDD). Často se mylně zaměňuje za pouhé “psaní testů v Gherkinu”, ale ve skutečnosti jde o hluboký proces zaměřený na pochopení a definici chování systému.
Jak Dan North “opravil” TDD
BDD nevzniklo ve vakuu. Na počátku tisíciletí si Dan North všiml, že lidé bojují s Test-Driven Developmentem (TDD). Otázky typu “Co mám testovat?”, “Kde mám začít?” nebo “Kolik testů je dost?” brzdily adopci této skvělé techniky.
Ve svém přelomovém článku Introducing BDD navrhl změnu perspektivy: Přestaňte mluvit o testech a začněte mluvit o chování (behavior).
Tato zdánlivě malá změna v terminologii měla obrovský dopad. Najednou se do diskuse mohli zapojit i netechničtí lidé. BDD zavedlo koncept “Společného jazyka” (Ubiquitous Language), který sjednocuje vývojáře, testery a byznys (často označované jako Three Amigos). Cílem není nic menšího než zajistit, aby všichni rozuměli tomu, co stavíme, ještě dříve, než napíšeme první řádek kódu.
Akceptační testy jako “lešení” podle Davea Farleyho
Pokud Dan North položil základy komunikace, Dave Farley (autor knih Continuous Delivery a Modern Software Engineering) dodal BDD inženýrskou hloubku. Farley často mluví o akceptačních testech jako o lešení (scaffolding).
Představte si stavbu domu. Lešení není součástí výsledné stavby, ale bez něj ji nepostavíte bezpečně a přesně. V softwaru plní BDD scénáře stejnou roli:
Vnější smyčka TDD: Zatímco unit testy ověřují detaily implementace (vnitřní smyčka), BDD scénáře řídí celkovou architekturu aplikace zvenčí.
Oddělení záměru od implementace: Dobře napsaný BDD test říká, co systém dělá (“Uživatel si může vybrat zboží”), nikoliv jak to dělá uvnitř databáze.
Podpora refaktorování: Díky tomu, že testy nejsou svázány s detaily kódu, můžete vnitřek aplikace kompletně přepsat. Pokud je lešení (akceptační test) stabilní, máte jistotu, že jste nerozbili byznysový záměr.
BDD v praxi: Více než jen Gherkin
Mnoho týmů začne u nástrojů jako Cucumber/SpecFlow a skončí u “upovídaných” scénářů, které nikdo nečte. Skutečné BDD stojí na metodě Specifikace příkladem. Místo abstraktních požadavků (“Systém musí být rychlý”) definujeme konkrétní příklady (“Pokud má uživatel v košíku 3 položky, sleva činí 10 %”).
Struktura Given-When-Then (Za předpokladu – Když se stane – Pak se stane) je víc než jen šablona. Je to způsob, jak strukturovat naše myšlení. Podívejte se na tento jednoduchý příklad scénáře pro e-shop:
Feature: Doprava zdarma při nákupu nad 1000 Kč
Scenario: Zákazník má nárok na dopravu zdarma
Given je v košíku zboží v hodnotě 1200 Kč
And zákazník zvolí standardní dopravu
When přejde k pokladně
Then cena za dopravu je 0 Kč
And celková cena objednávky je 1200 Kč
Scenario: Zákazník platí dopravu u malého nákupu
Given je v košíku zboží v hodnotě 800 Kč
When přejde k pokladně
Then cena za dopravu je 50 Kč
And celková cena objednávky je 850 Kč
Tento formát zajišťuje:
Given: Kontext (stav systému).
When: Akce (klíčová událost).
Then: Očekávaný výsledek (pozorovatelné chování).
Proč je BDD klíčové zejména pro velké produkty?
Ve velkém měřítku se komplexita násobí. Koordinace deseti týmů na jednom produktu je bez jasných spustitelných specifikací téměř nemožná. BDD zde funguje jako:
Definice “Hotovo” (Done): Funkce je hotová až tehdy, když projdou akceptační testy definované s byznysem.
Redukce přepisování: Týmy tráví méně času opravami nedorozumění, protože zadání bylo vyjasněno na příkladech hned na začátku.
Živá dokumentace: Scénáře se spouštějí v CI/CD pipeline. Pokud testy projdou, víme, že dokumentace systému stále odpovídá realitě.
Závěr: BDD jako mindset technické excelence
BDD není o nástrojích, je to o lidech a porozumění. Je to investice do komunikace, která se vrací v podobě nižšího technického dluhu a vyšší důvěry mezi IT a byznysem.
Pokud chcete začít, neřešte hned instalaci Cucumberu. Sejděte se s kolegy u tabule a zkuste popsat příští funkci pomocí konkrétních příkladů. Začněte dialogem, ne nástrojem.