Gherkin / Given When Then

1. Co je Gherkin?

Gherkin je jednoduchý, čitelný jazyk používaný pro popis chování systému. Nejčastěji se používá v přístupu BDD (Behavior Driven Development), kde spolupracuje business analytik, vývojář i QA nad stejnou specifikací.

Hlavní výhody Gherkinu:

Čitelný pro business i technické role
Slouží jako dokumentace i automatizovaný test
Sjednocuje komunikaci mezi týmy
Podporuje BDD přístup

Často používané frameworky:

Cucumber
SpecFlow
Behave
JBehave
Robot Framework

2. Základní syntaxe

Feature

Popisuje hlavní funkcionalitu nebo business capability.

Feature: Wallet payment processing

Doporučení:

Název má být stručný a business-oriented
Feature by měla řešit jednu oblast systému
Je vhodné doplnit business kontext

Feature: Wallet payment processing

  In order to pay using wallet balance
  As a registered customer
  I want to complete wallet transactions securely

Scenario

Konkrétní use case nebo situace.

Scenario: Successful wallet payment

Každý scénář by měl testovat jednu věc
Scénáře mají být nezávislé
Mají být srozumitelné i bez znalosti implementace

Given / When / Then

Klíčové slovo	Význam
Given	Výchozí stav systému nebo předpoklad
When	Akce uživatele nebo systému
Then	Očekávaný výsledek
And	Rozšíření předchozího kroku
But	Výjimka nebo negativní podmínka

3. Typický scénář

Scenario: User completes payment successfully
  Given the user has sufficient wallet balance
  And the wallet service is available
  When the user submits a payment request
  Then the payment is processed successfully
  And the wallet balance is reduced
  And a transaction record is created

Tento scénář obsahuje:

Výchozí stav systému
Business akci
Očekávaný výsledek
Vedlejší efekty systému

4. Dobrá praxe

Dobrý Gherkin scénář:

Popisuje chování systému, ne implementaci
Je čitelný pro business i technické role
Je jednoznačný a testovatelný
Neobsahuje zbytečné UI detaily
Má jasný expected outcome

Dobrá ukázka

Scenario: User sees pending status when provider confirmation is delayed
  Given the user has submitted a wallet payment
  And the payment provider has not confirmed the payment yet
  When the user opens the transaction detail
  Then the payment status is displayed as Pending
  And the user is informed that confirmation may take several minutes

Proč je scénář dobrý:

Popisuje business behavior
Neřeší technickou implementaci
Obsahuje jasný expected result
Je srozumitelný bez znalosti UI

Slabá ukázka

Scenario: Click buttons
  Given I click the menu
  When I click the payment button
  Then I click status

Proč je scénář špatný:

Není jasné, co se testuje
Obsahuje pouze klikání v UI
Neověřuje business výsledek
Je křehký při změně UI

5. Anti-patterny

Příliš technický scénář

Scenario: API returns 200
  Given endpoint /api/v1/payment exists
  When POST request is sent with JSON payload
  Then response code is 200

Problémy:

Řeší implementaci místo business chování
Není čitelný pro business

Příliš dlouhý scénář

Pokud scénář obsahuje 15–20 kroků, většinou testuje příliš mnoho věcí najednou.

Doporučení:

Rozdělit na menší scénáře
Každý scénář by měl mít jeden hlavní cíl

6. Scenario Outline

Slouží pro parametrizované scénáře se stejnou logikou a různými daty.

Scenario Outline: User login validation
  Given the user enters username "<username>"
  And the user enters password "<password>"
  When the user submits login
  Then the login result should be "<result>"

Examples:
  | username | password | result  |
  | admin    | admin123 | success |
  | admin    | wrong    | failed  |
  | user     | pass123  | success |

Výhody:

Méně duplicitního textu
Lepší maintenance
Větší pokrytí datových kombinací

7. Background

Background obsahuje kroky společné pro více scénářů.

Feature: Wallet payments

Background:
  Given the user is logged in
  And the wallet service is available

Scenario: Successful payment
  When the user submits payment
  Then the payment is successful

Scenario: Failed payment
  When the user submits payment with insufficient balance
  Then the payment is rejected

Doporučení:

Background má obsahovat jen opravdu společné kroky
Příliš dlouhý Background zhoršuje čitelnost

8. Tagy

Tagy slouží k organizaci a filtrování scénářů.

@smoke
@regression
@payments

Scenario: Successful wallet payment
  Given ...
  When ...
  Then ...

Časté tagy:

@smoke — základní kritické testy
@regression — regresní testy
@integration — integrační testy
@slow — pomalé scénáře
@wip — work in progress

9. Doporučení pro psaní scénářů

Používej business jazyk
Vyhýbej se UI detailům
Scénáře piš krátké a přehledné
Každý scénář by měl mít jeden účel
Then kroky musí být ověřitelné
Používej konzistentní terminologii
Nepiš zbytečné kroky typu „kliknu na tlačítko“

10. Rozdíl mezi BDD a klasickými testy

BDD / Gherkin	Klasický test case
Business-oriented	Technicky orientovaný
Čitelný pro všechny role	Často jen pro QA
Popisuje chování	Popisuje kroky
Vhodný pro automatizaci	Často manuální

11. Pokročilé doporučení

Testuj business hodnotu

„Jaké chování systému je důležité pro uživatele nebo business?“

Vyhýbej se křehkým scénářům

Scénáře založené na konkrétních UI detailech se často rozbijí při redesignu aplikace.

Používej doménový jazyk

Raději:

Then the transaction status is displayed as Completed

Než:

Then transaction status = 2

12. Shrnutí

Gherkin je silný nástroj pro propojení business požadavků, QA a automatizace testů.

Dobře napsaný scénář:

Popisuje business behavior
Je čitelný a jednoznačný
Neřeší implementační detaily
Může sloužit jako dokumentace i automatizovaný test

„Popisuj co systém dělá, ne jak je implementovaný.“