Gherkin: syntax, BDD testovanie a písanie scenárov

Autor:  Michaela Kojnoková

Testovanie • 13 min. čítania • 25. 8. 2026

Autor:  Michaela Kojnoková •

Testovanie • 13 min. čítania • 25. 8. 2026

Gherkin je špecializovaný jazyk pre písanie testovacích scenárov v prístupe vývoja riadeného správaním (Behavior-Driven Development, BDD). Spája ľudsky čitateľný popis správania softvéru s automatizovaným testovaním. Ak pracuješ v BDD tíme alebo sa chceš naučiť písať testovací scenár, ktorý pochopí každý člen tímu, osvoj si syntax jazyka Gherkin (Gherkin syntax), kľúčové slová, štruktúru .feature file a osvedčené postupy, ktoré odlišujú dobrý scenár od zlého.

Čo je Gherkin a prečo vznikol

Gherkin je jednoduchý, štruktúrovaný jazyk pre popis správania softvéru tak, aby mu rozumel každý člen tímu. Jeho syntax vychádza z prirodzeného jazyka a kombinuje ho s pevne danými kľúčovými slovami, ktoré framework Cucumber dokáže prečítať a spustiť ako test.

Vznikol ako súčasť ekosystému BDD testovania, kde sa požiadavky definujú formou testovacích scenárov, nie abstraktných dokumentov. Scenár v Gherkine opisuje, čo by systém mal robiť v konkrétnej situácii: nie ako to technicky funguje, ale čo sa od neho očakáva. V tomto zmysle je Gherkin špecifikačný jazyk (executable specification), nie testovací framework.

Gherkin je jazyk, ktorý interpretuje framework Cucumber: open-source nástroj na automatizáciu BDD testov. Jeho popularitu podčiarkuje priama integrácia s frameworkmi ako Cucumber, SpecFlow alebo Behave.

Čo je BDD – Behavior-Driven Development?

BDD testovanie (testovanie riadené správaním) je agilná metodika vývoja softvéru, pri ktorej sa aplikácia dokumentuje a testy sa navrhujú na základe správania, ktoré používateľ očakáva pri interakcii s aplikáciou, pričom tieto scenáre sa neskôr zapisujú v jazyku Gherkin. Namiesto abstraktných dokumentov sa požiadavky definujú formou konkrétnych testovacích scenárov, ktorým rozumie každý člen tímu: tester, developer aj product owner.

Celý prístup vývoja riadeného správaním (Behavior-Driven Development) sa v praxi často zhrnuje do troch fáz: Discovery (objavovanie požiadaviek cez konverzáciu), Formulation (formulácia príkladov do scenárov) a Automation (automatizácia scenárov ako spustiteľných testov). Toto je dôvod, prečo BDD nie je len technika písania testov, ale aj spôsob, ako prepojiť biznis a vývoj.

V BDD tímoch sa často spomína koncept Three Amigos: stretnutie business analytika (alebo product ownera), developera a testera, na ktorom spoločne definujú akceptačné kritériá. Tento formát funguje preto, lebo nedorozumenia o tom, čo má systém robiť, sa odhalia ešte pred napísaním kódu, nie až pri reklamácii používateľa.

Gherkin vs. Cucumber – aký je medzi nimi rozdiel

Jednou z najčastejších otázok pri učení BDD je: Je Gherkin a Cucumber to isté? Nie. Sú to dva odlišné koncepty, ktoré sa navzájom dopĺňajú.

Zjednodušene teda môžeme povedať, že Gherkin je jazyk, Cucumber je interpret. Gherkin napíšeš do .feature file, Cucumber ho načíta, priradí každému kroku príslušnú Step Definition a vykoná test. Bez Gherkinu by Cucumber nemal čo čítať.

Gherkin syntax – kľúčové slová a štruktúra

Každý súbor funkcionality (.feature file) sa riadi rovnakou hierarchickou štruktúrou, ktorú definuje Gherkin syntax. Feature opisuje funkciu, Scenario opisuje konkrétny prípad a kroky Given/When/Then definujú, čo sa deje. Pochopenie tejto štruktúry je predpoklad pre písanie akéhokoľvek BDD scenára.

Feature a Rule – definícia funkcionality

Feature je najvyššia úroveň .feature file. Obsahuje názov a voliteľný popis funkcionality. Tento popis nie je testovateľný kód, slúži na kontext a dokumentáciu.

Feature: Prihlásenie používateľa
  Ako registrovaný používateľ
  Chcem sa prihlásiť do systému
  Aby som mal prístup k svojmu účtu

Od Gherkinu verzie 6 je k dispozícii aj kľúčové slovo Rule, ktoré reprezentuje jedno obchodné pravidlo zoskupujúce viacero scenárov. Rule je voliteľné: použiješ ho vtedy, keď chceš v rámci jednej Feature explicitne oddeliť skupiny scenárov podľa pravidla, ktoré overujú.

Scenario a Scenario Outline – konkrétny testovací prípad

Scenario je základná jednotka testovania v Gherkine. Každý testovací scenár (test scenario) by mal testovať práve jednu konkrétnu situáciu. Ak scenár testuje viac vecí naraz, je to signál, že ho treba rozdeliť.

Scenario: Úspešné prihlásenie so správnymi údajmi
  Given používateľ je na prihlasovacej stránke
  When zadá správne meno a heslo
  Then je presmerovaný na dashboard

Náčrt scenára (Scenario Outline) umožňuje spustiť rovnaký testovací scenár s rôznymi vstupnými dátami. Namiesto duplicitných scenárov napíšeš jeden šablónovitý a dáta zadáš cez sekciu Examples.

Scenario Outline: Prihlásenie s rôznymi rolami
  Given používateľ s rolou <rola> je na prihlasovacej stránke
  When zadá platné prihlasovacie údaje
  Then uvidí dashboard prislúchajúci roli <rola>

  Examples:
    | rola   |
    | admin  |
    | editor |
    | viewer |

Cucumber spustí tento scenár trikrát, raz pre každý riadok v tabuľke Examples. Výsledok: tri testy, jeden scenár v kóde.

Scenario Outline sa oplatí použiť vtedy, keď rovnaký tok testuješ s troma a viac rôznymi vstupmi. Pre jeden alebo dva prípady je jednoduchší samostatný Scenario: kód je kratší a chyba je okamžite viditeľná bez nutnosti hľadať, ktorý riadok tabuľky Examples zlyhal.

Každý riadok v tabuľke Examples sa v CI/CD reporte zobrazí ako samostatný testovací prípad s vlastným názvom. To uľahčuje identifikáciu konkrétneho vstupu, pri ktorom test padol: napríklad „Prihlásenie s rôznymi rolami [viewer]“ jasne ukáže, že problém sa týka len roly viewer, nie celej funkcionality.

Given, When, Then – tri kroky každého scenára

Toto sú tri piliere Gherkin syntaxe. Každý krok má jasný zmysel:

• Given – stav pred akciou (predpoklad, kontext). Popisuje situáciu, v ktorej sa systém nachádza pred tým, ako sa niečo stane.
• When – akcia alebo udalosť, ktorú používateľ alebo systém vykoná. Toto je jadro scenára: čo sa testuje.
• Then – očakávaný výsledok. Čo by malo nastať po akcii. Tu Cucumber overí, či systém reagoval správne.

Kľúčové slová And a But rozširujú kroky bez opakovania Given/When/Then. Cucumber ich spracuje rovnako ako predchádzajúci krok rovnakého typu.

Given používateľ je prihlásený
  And má administrátorské práva
  When otvorí sekciu nastavení
  Then uvidí možnosť správy používateľov
  But nezobrazí sa mu fakturačná sekcia

Odporúčame ti…

Udržiavaj každý krok čo najstručnejší a najkonkrétnejší. Ak jeden krok Given opisuje tri rôzne predpoklady, rozdeľ ho pomocou And. Jasnosť scenára je dôležitejšia ako počet krokov.

Background – spoločný kontext pre všetky scenáre

Pozadie scenára (Background) definuje kroky, ktoré sa vykonajú pred každým scenárom v danom .feature file. Používaj ho vtedy, keď viacero scenárov zdieľa rovnaké predpoklady, napríklad prihlásenie alebo inicializáciu databázy.

Background:
  Given databáza je inicializovaná testovacími dátami
  And administrátor je prihlásený do systému

Background sa vykoná pred každým Scenario a Scenario Outline v súbore. Ak kroky presahujú tri riadky, zváž, či ich radšej nepresunúť do Step Definitions.

Typický prípad vhodný pre Background je e-shop, kde každý scenár predpokladá prihlásenie a naplnený košík. Namiesto opakovania tých istých Given krokov v desiatich scenároch ich raz definuješ v Background a .feature file ostane prehľadný.

Background má však aj limity. Ak sa predpoklady líšia scenár od scenára (napríklad raz testuješ admina, inokedy bežného používateľa), Background nie je správna voľba. V takom prípade je čistejším riešením uviesť kontext priamo v Given krokoch každého scenára, aby bol každý testovací prípad čitateľný samostatne bez nutnosti skrolovať na začiatok súboru.

Data Tables a Doc Strings – štruktúrované vstupné dáta

Dátová tabuľka (Data Table) sa používa priamo v kroku scenára, keď potrebuješ odovzdať väčšie množstvo štruktúrovaných dát. Na rozdiel od Examples nie je viazaná na Scenario Outline: ide do jedného konkrétneho kroku.

Given systém obsahuje nasledujúcich používateľov:
  | meno  | email           | rola   |
  | Ján   | jan@firma.sk    | admin  |
  | Mária | maria@firma.sk  | editor |

Doc Strings sú alternatíva, ak potrebuješ do kroku odovzdať dlhší blok textu, napríklad obsah e-mailu alebo JSON payload. Označujú sa tromi úvodzovkami nad a pod blokom textu a Cucumber ich pošle do Step Definitions ako jeden reťazec.

Tags – filtrovanie a organizácia testov

Tagy (značky) umožňujú kategorizovať scenáre a spúšťať len ich podmnožiny. Typicky sa používajú na označenie smoke testov, regresných testov alebo testov pre konkrétne prostredie.

@smoke @regression
Scenario: Overenie dostupnosti hlavnej stránky

Cucumber potom spustíš len so scenármi s konkrétnym tagom. To dramaticky zrýchli CI/CD pipeline, keď potrebuješ rýchlu spätnú väzbu po deploy.

Odporúčame ti…

Dohodni si s tímom naming convention pre tagy ešte pred prvým sprintom. Napríklad @smoke pre rýchle kritické testy, @regression pre plné testovacie sady a @wip pre scenáre, ktoré sa ešte vyvíjajú. Bez dohody sa tagy rýchlo zmenia na chaos.

Okrem organizačných tagov sa v praxi používajú aj tagy pre prostredia: napríklad @staging alebo @production. Cucumber umožňuje kombinovať tagy pomocou logických operátorov: spustenie testov s tagom @smoke AND NOT @wip zabezpečí, že sa vykonajú len hotové smoke testy a vynechajú sa scenáre, ktoré sú ešte vo vývoji.

Praktický príklad na Gherkin test

Najlepší spôsob, ako pochopiť Gherkin v praxi, je vidieť kompletný .feature file s reálnym scenárom. Tu je ukážka pre e-shop checkout, ktorá kombinuje všetky kľúčové slová syntaxe.

Feature: Checkout v e-shope
  Aby zákazník mohol dokončiť nákup,
  systém musí správne spočítať cenu a vytvoriť objednávku.

  Background:
    Given zákazník je prihlásený
    And v košíku má 2 produkty

  @smoke
  Scenario: Úspešné dokončenie objednávky
    When zákazník zadá platnú dodaciu adresu
    And vyberie platbu kartou
    And potvrdí objednávku
    Then sa zobrazí potvrdzovacia stránka
    And zákazník dostane e-mail s potvrdením

  Scenario Outline: Aplikácia zľavového kódu
    When zákazník zadá zľavový kód <kod>
    Then sa celková cena zníži o <zlava> %

    Examples:
      | kod      | zlava |
      | LETO10   | 10    |
      | VIP20    | 20    |

Dobrý vs. zlý scenár – porovnanie

Rovnaký scenár sa dá napísať dobre aj zle. Rozdiel je v tom, či scenár opisuje správanie z pohľadu používateľa, alebo implementačné detaily systému.

• Zlý scenár (implementačný detail):

Scenario: Login
  Given otvorím URL /login
  When zadám do inputu #email „test@firma.sk"
  And zadám do inputu #password „Heslo123"
  And kliknem na tlačidlo s ID #submit-btn
  Then URL obsahuje /dashboard

• Dobrý scenár (zameraný na správanie):

Scenario: Úspešné prihlásenie registrovaného používateľa
  Given používateľ má platný účet
  When sa prihlási so správnymi údajmi
  Then je presmerovaný do svojho dashboardu

Zlý scenár opisuje, ako sa test technicky spraví. Dobrý opisuje, čo používateľ chce dosiahnuť. Cucumber môže obidva spustiť, ale len druhý bude po roku stále zrozumiteľný pre nového člena tímu a po refaktoringu UI nevyhodí test pre zmenu ID tlačidla.

Robot Framework vs Cucumber: Ktorý nástroj zvoliť pre BDD testing

Oba nástroje podporujú čitateľné testy, ale majú odlišnú filozofiu. Výber závisí od potrieb tímu a technologického stacku.

Ak tím aktívne praktizuje vývoj riadený správaním (Behavior-Driven Development) a chce zapojiť product ownerov do tvorby scenárov, Cucumber s Gherkinom je silnejšia voľba. Robot Framework vynikne tam, kde tím preferuje Python a nepotrebuje striktné BDD formáty.

Osvedčené postupy pre písanie scenárov

Osvedčené postupy (best practices) pre Gherkin nie sú len estetika. Zlý scenár je ťažko udržiavateľný, generuje falošné alarmy a stráca dokumentačnú hodnotu. Tu sú konkrétne pravidlá, ktoré fungujú.

Jeden scenár = jedna vec

Každý testovací scenár by mal testovať presne jednu situáciu. Ak scenár obsahuje viac ako 5 – 6 krokov alebo overuje viacero výsledkov v jednom Then, je príliš komplexný. Rozdeľ ho.

Píš z pohľadu používateľa, nie systému

Zlé: When klikne na tlačidlo s ID #submit-btn. To je implementačný detail, nie správanie. Dobré: When odošle objednávku. Toto popisuje zámer. Scenár by mal byť čitateľný aj pre niekoho bez programátorských znalostí.

Vyhni sa technickým detailom v scenároch

Gherkin nie je technická dokumentácia. SQL dotazy, XPath selektory ani HTTP status kódy do scenárov nepatria: tie patria do Step Definitions.

Background používaj s mierou

Background je lákavá skratka, ale ak každý scenár v .feature file vyžaduje iné predpoklady, nie je správny nástroj. Príliš dlhý Background zahmlieva kontext jednotlivých scenárov.

Konzistentný jazyk v celom tíme

Dohodnite sa s tímom na spoločnom slovníku. Ak niekde píšeš „používateľ je prihlásený“ a inde „je aktívna session“, Cucumber to bude považovať za dva rôzne kroky, aj keď znamenajú to isté.

Odporúčame ti…

Vytvor si glossary Gherkin výrazov pre váš projekt: Excel alebo Confluence stránku s dohodnutými formuláciami krokov. Šetrí to hodiny ladenia Step Definitions a zabraňuje duplicitám v kóde. Rovnaký krok má mať vždy rovnaké znenie.

Cucumber testing – ako Gherkin ožíva v kóde

Testovanie s Cucumber (Cucumber testing) prepojí .feature file s definíciami krokov (Step Definitions): funkciami v kóde, ktoré vykonajú každý krok scenára. Toto prepojenie je srdce BDD testovania.

Príklad Step Definitions v Jave pre scenár prihlásenia

@Given("používateľ je na prihlasovacej stránke")
public void userIsOnLoginPage() {
    driver.get("https://app.example.com/login");
}

@When("zadá správne meno a heslo")
public void userEntersValidCredentials() {
    loginPage.enterUsername("testuser");
    loginPage.enterPassword("securePass123");
    loginPage.clickLogin();
}

@Then("je presmerovaný na dashboard")
public void userIsRedirectedToDashboard() {
    assertTrue(driver.getCurrentUrl().contains("/dashboard"));
}

Cucumber funguje s populárnymi testovacími nástrojmi vrátane Selenium, Playwright alebo Cypress. Slúži ako vrstva nad nimi, ktorá sa stará o parsovanie .feature file a volanie správnych Step Definitions.

Step Definitions sú funkcie v programovacom jazyku, ktoré mapujú každý Gherkin krok na konkrétnu akciu v kóde. Jeden Step Definition môže pokryť viacero scenárov: ak napíšeš rovnaký Given krok v desiatich rôznych scenároch, Cucumber zavolá ten istý kus kódu, čím sa eliminuje duplicita v testovacej logike.

Pri práci s väčšími projektmi sa Step Definitions zvyčajne organizujú do samostatných tried alebo súborov podľa domény: napríklad LoginSteps, CheckoutSteps, UserManagementSteps. Táto štruktúra uľahčuje údržbu: keď sa zmení prihlasovací tok, upravíš jediný súbor, nie desiatky testov roztrúsených po celom projekte.

Výhody BDD testovania s Gherkinom

BDD testovanie s Gherkinom má pre tímy niekoľko jasných výhod:

• Scenáre sú čitateľné pre celý tím vrátane netechnických členov: product owner vie overiť, že scenár zodpovedá požiadavke.
• Testy slúžia ako živá dokumentácia (living documentation): vždy odrážajú aktuálny stav systému, nie zastaraný Word dokument.
• Jednoduchá integrácia do CI/CD pipeline: Cucumber beží v každom populárnom CI/CD nástroji.
• Scenario Outline eliminuje duplicitný kód pri testovaní viacerých dátových sád.
• Spoločný jazyk (Gherkin) redukuje nedorozumenia medzi biznisom a vývojovým tímom.

Nevýhody BDD testovania s Gherkinom

Nevýhody BDD testovania s Gherkinom sa spájajú najmä s réžiou okolo scenárov a stojí za to poznať ich skôr, než sa preň rozhodneš:

• Písanie dobrých scenárov si vyžaduje prax. Zlé scenáre sú horšie ako žiadne.
• Udržiavanie Step Definitions môže byť nákladné, ak sa Gherkin text mení bez refaktoringu kódu.
• BDD funguje len vtedy, keď celý tím (vrátane product ownera) aktívne participuje na tvorbe scenárov.
• Pre čisto technické unit testy je Gherkin nadmerný: tu je lepší priamy testovací framework.

Nástroje pre Gherkin a BDD testovanie

Gherkin scenáre sa najčastejšie spúšťajú automaticky v rámci CI/CD pipeline, čo zabezpečuje kontinuálnu validáciu správania aplikácie.

Alternatívou ku Cucumber je Robot Framework: open-source nástroj s keyword-driven prístupom, ktorý je populárny najmä v Python ekosystéme a pri testovaní bez BDD formátu.

Na správu a organizáciu Gherkin scenárov v tíme môžeš využiť test management nástroj ako Testomatio: efektívny nástroj pre agilné, DevOps a CI/CD tímy, ktorý podporuje import .feature súborov a správu Gherkin scenárov.

Medzi komerčné nástroje s BDD podporou patrí aj Katalon: platforma na automatizáciu testov s natívnou integráciou CI/CD a DevOps, ktorá umožňuje písať BDD testy v Gherkin syntaxi.

Zdieľaj článok

Gherkin: syntax, BDD testovanie a písanie scenárov

O autorovi

Michaela Kojnoková

Agile Test Engineer

Po štúdiu informatiky na ŽU a TUKE som sa najviac ponorila do oblasti automatizácie testovania. Okrem toho sa venujem tvorbe webov, databázam, dátovej analytike, umelej inteligencii a strojovému učeniu. Mám rada cestovanie, šport a najviac si užívam čas strávený v prírode s mojimi blízkymi. LinkedIn