BDD vs Gherkin

A Behavior Driven Development (BDD) egy szoftverfejlesztési folyamat, amely az együttműködés javítására törekszik. A rendszer viselkedését a felhasználó szemszögéből határozza meg, természetes nyelven írt specifikációk segítségével.

A BDD a Test Driven Development (TDD) evolúciójaként alakult ki, egy felhasználó-központúbb megközelítéssel a követelmények és a rendszer viselkedése felé. Ez a megközelítés segít biztosítani, hogy a szoftverfejlesztés jobban igazodjon a végfelhasználó elvárásaihoz és igényeihez.

A TDD-től a BDD felé történő átmenet a kódbázison alapuló tesztekről a rendszer viselkedésén alapuló tesztek felé való elmozdulást jelenti, amely lehetővé teszi a felhasználói igények mélyebb megértését.

A BDD a Gherkin nyelvet használja, hogy a specifikációkat a technikai és nem technikai csapattagok számára is érthetővé tegye. Ez lehetővé teszi, hogy a specifikációk közös igazságforrásként működjenek, javítva a kommunikációt és csökkentve a félreértéseket.

A BDD elősegíti a várt szoftverviselkedés közös megértését, biztosítva, hogy minden érintett, beleértve a nem technikai érdekelt feleket is, tisztában legyen a projekt céljaival.

A Gherkin egy strukturált specifikációs nyelv, amelyet szoftverrendszerek elvárt viselkedésének leírására használnak oly módon, hogy az mind az üzleti érintettek, mind a fejlesztők számára érthető legyen. A Gherkin a Viselkedésvezérelt Fejlesztés (BDD - Behavior-Driven Development) egyik alapvető eszköze, amely hidat képez az üzleti követelmények és az automatizált tesztek között.

A "Gherkin" (angolul: uborka) neve a Cucumber tesztelési keretrendszerrel való szoros kapcsolatából ered. A Gherkin természetes nyelvű kulcsszavakra épülő szintaxist használ, amely lehetővé teszi, hogy bárki elolvashassa és megértse a szoftver specifikációit, függetlenül a technikai háttértől.

Mi az a BDD?

A Behavior-Driven Development (Viselkedésvezérelt Fejlesztés) egy szoftverfejlesztési módszertan, amely a Test-Driven Development (TDD) kiterjesztése, és az együttműködésre helyezi a hangsúlyt a fejlesztők, tesztelők és üzleti érintettek között. Az alapötlet az, hogy a szoftvert az elvárt viselkedés szempontjából kell leírni, nem pedig a technikai megvalósítás oldaláról.

A BDD három fő előnye:

1. Közös megértés: Mindenki ugyanúgy érti a követelményeket
2. Élő dokumentáció: A specifikációk mindig naprakészek maradnak
3. Korai visszajelzés: A félreértések már a fejlesztés előtt kiderülnek

A három barát (Three Amigos)

A BDD-ben egy alapvető gyakorlat a "Three Amigos" (Három Barát) munkamenet, ahol három kulcsszerep működik együtt a specifikációk meghatározásában:

1. Üzleti/Terméktulajdonos: Meghatározza a "mit" és a "miért"
2. Fejlesztő: Értékeli a "hogyan"-t és azonosítja a technikai komplexitásokat
3. Tesztelő/QA: Azonosítja a szélsőséges eseteket, negatív forgatókönyveket és elfogadási kritériumokat

Ezek a munkamenetek Gherkin forgatókönyveket eredményeznek, amelyek a rendszer élő dokumentációjaként szolgálnak.

Feature (Funkció)

Minden Gherkin fájl a Feature kulcsszóval kezdődik, amely a magas szintű funkcionalitást írja le:

Feature: Felhasználói bejelentkezés Mint regisztrált felhasználó Szeretnék bejelentkezni a platformra Hogy hozzáférhessek a személyes adataimhoz

Scenario (Forgatókönyv)

Egy Scenario a funkció egy konkrét használati esetét képviseli:

Scenario: Bejelentkezés érvényes hitelesítő adatokkal Given a felhasználó a bejelentkezési oldalon van When megadja az email címet "[email protected]" és a jelszót "Jelszo123" And rákattint az "Bejelentkezés" gombra Then átirányítódik az irányítópultra And látja a "Üdvözöljük, Péter" üzenetet

Given-When-Then: a Gherkin szíve

A három fő kulcsszó strukturálja az egyes forgatókönyveket:

And és But

Több feltétel hozzáadásához:

Scenario: Regisztráció hiányos adatokkal Given a felhasználó a regisztrációs oldalon van And kitöltötte a név mezőt "Péter" értékkel But nem töltötte ki az email mezőt When rákattint a "Regisztráció" gombra Then hibaüzenetet lát: "Az email cím kötelező" And az űrlap nem kerül elküldésre

Scenario Outline (Forgatókönyv vázlat)

Ugyanazon logika különböző adatokkal történő teszteléséhez a Scenario Outline használható Examples táblázattal:

Scenario Outline: Jelszó validáció Given a felhasználó a regisztrációs oldalon van When megadja a jelszót "<jelszo>" Then a rendszer a következő üzenetet jeleníti meg: "<uzenet>" Examples: | jelszo | uzenet | | abc | A jelszónak legalább 8 karakternek kell lennie | | abcdefgh | A jelszónak tartalmaznia kell számot | | Abcdefg1 | Érvényes jelszó |

Background (Háttér)

A Background a feature összes forgatókönyvéhez közös lépéseket definiálja:

Feature: Kosár kezelése Background: Given a felhasználó be van jelentkezve And legalább egy termék elérhető a katalógusban Scenario: Termék hozzáadása a kosárhoz When hozzáadja a "Laptop Pro" terméket a kosárhoz Then a kosár 1 tételt mutat Scenario: Termék eltávolítása a kosárból Given a kosár tartalmazza a "Laptop Pro" terméket When eltávolítja a "Laptop Pro" terméket Then a kosár üres

Címkék (Tags)

A címkék lehetővé teszik a forgatókönyvek kategorizálását és szűrését:

@smoke @bejelentkezes Scenario: Alap bejelentkezés Given a felhasználó a bejelentkezési oldalon van ... @regresszio @kosar Scenario: Többszörös hozzáadás a kosárhoz ...

A Cucumber az a keretrendszer, amely a Gherkin specifikációkat végrehajtható tesztekké alakítja.

A teljes folyamat

1. Specifikációk megírása .feature fájlokban a Gherkin szintaxis használatával
2. Step definition-ök implementálása: kód, amely összeköti az egyes Gherkin lépéseket egy automatizált művelettel
3. Cucumber futtatása: a keretrendszer beolvassa a .feature fájlt, megtalálja a megfelelő step definition-öket és végrehajtja azokat
4. Eredmények elemzése: a Cucumber jelentést generál a sikeres és sikertelen forgatókönyvekről

Step definition példa (Java)

@Given("a felhasználó a bejelentkezési oldalon van") public void felhasznalo_a_bejelentkezesi_oldalon() { driver.navigate().to("https://app.pelda.hu/login"); } @When("megadja az email címet {string} és a jelszót {string}") public void megadja_a_hitelesito_adatokat(String email, String jelszo) { driver.findElement(By.id("email")).sendKeys(email); driver.findElement(By.id("password")).sendKeys(jelszo); } @Then("átirányítódik az irányítópultra") public void ellenorzi_az_atiranyitast() { assertEquals("https://app.pelda.hu/dashboard", driver.getCurrentUrl()); }

Step definition példa (JavaScript/TypeScript)

Given('a felhasználó a bejelentkezési oldalon van', async function() { await browser.url('/login'); }); When('megadja az email címet {string} és a jelszót {string}', async function(email, jelszo) { await $('#email').setValue(email); await $('#password').setValue(jelszo); }); Then('átirányítódik az irányítópultra', async function() { await expect(browser).toHaveUrl('/dashboard'); }); 

Deklaratív, nem imperatív stílus

Imperatív (kerülendő):

When rákattint az "email" mezőre And beírja a "[email protected]" címet And rákattint a "jelszó" mezőre And beírja a "Jelszo123" jelszót And rákattint a "Bejelentkezés" gombra

Deklaratív (javasolt):

When bejelentkezik a "[email protected]" email és "Jelszo123" jelszó használatával

A deklaratív stílus olvashatóbb, kevésbé törékeny a UI-változásokkal szemben, és a viselkedésre összpontosít a megvalósítás helyett.

Egy forgatókönyv, egy viselkedés

Minden forgatókönyvnek egyetlen viselkedést kell tesztelnie. A túl hosszú forgatókönyvek, amelyek többféle viselkedést is ellenőriznek, nehezen karbantarthatók és hibakereshetők.

A tartomány nyelvének használata

A forgatókönyveket az üzleti terminológia használatával kell megírni, nem a kód nyelvén. Ha az üzlet "megrendelésekről" beszél, ne használjon "adatbázis rekordot". A tartományvezérelt tervezés (DDD) nyelvezete tökéletesen alkalmazható itt.

Független forgatókönyvek

Minden forgatókönyvnek képesnek kell lennie elszigetelten futni, anélkül, hogy más forgatókönyvek előzetes végrehajtásától függne.

Implementációs részletek elkerülése

Ne tartalmazzon technikai részleteket, mint CSS szelektorok, adatbázis-táblanevek vagy specifikus URL-ek a .feature fájlokban. Ezek a részletek a step definition-ökbe tartoznak.

A Gherkin egyik legérdekesebb jellemzője, hogy több mint 70 nyelvet támogat. A kulcsszavak magyarul is megírhatók:

# language: hu Jellemző: Rendeléskezelés Mint az üzlet adminisztrátora Szeretném kezelni a rendeléseket Hogy hatékony szolgáltatást biztosítsak Forgatókönyv: Új rendelés létrehozása Adott hogy a "Kovács János" ügyfél regisztrált Amikor létrehoz egy rendelést az "Espresso Gép" termékkel Akkor a rendelés "Függőben" állapottal jön létre És visszaigazoló email kerül kiküldésre

A magyar kulcsszavak:

• Jellemző (Feature)
• Forgatókönyv (Scenario)
• Adott (Given)
• Amikor (When)
• Akkor (Then)
• És (And)
• De (But)

A Gherkin fájlok egyik legjelentősebb előnye, hogy a rendszer mindig naprakész dokumentációjaként szolgálnak:

• Ha egy teszt sikertelen, a megfelelő dokumentáció automatikusan érvénytelenként jelölődik
• Az új csapattagok a .feature fájlok elolvasásával megérthetik a rendszer viselkedését
• Az érintettek természetes nyelvű forgatókönyvek olvasásával validálhatják a követelményeket
• A dokumentáció nem avulhat el, mert a tesztcsomag részeként kerül végrehajtásra

A Gherkin programozási nyelv?

Nem. A Gherkin egy specifikációs nyelv (DSL - Domain Specific Language), amelyet a szoftver viselkedésének olvasható módon történő leírására terveztek. Nem tartalmaz programozási logikát: azt a step definition-ökben valósítjuk meg egy valódi programozási nyelven.

Ki írja a Gherkin forgatókönyveket?

Ideális esetben a Gherkin forgatókönyveket közösen írják a Three Amigos munkamenetek során. A Terméktulajdonos meghatározza az elvárt viselkedést, a Tesztelő azonosítja a szélsőséges eseteket, a Fejlesztő pedig validálja a technikai megvalósíthatóságot.

A Gherkin csak Cucumberrel működik?

Nem. A Gherkin egy szabványos formátum, amelyet számos tesztelési keretrendszer támogat: SpecFlow (.NET), Behave (Python), Behat (PHP), Karate (API tesztelés) és sok más. A Cucumber a legismertebb, de nem az egyetlen.

Hány forgatókönyv legyen egy feature-ben?

Nincs fix szám, de általános szabály, hogy egy feature-ben 3 és 10 közötti forgatókönyv legyen. Ha túl sok a forgatókönyv, valószínűleg a feature túl tág, és fel kellene osztani.

A Gherkin alkalmas egységtesztekhez?

Általában nem. A Gherkin elfogadási tesztekhez és magas szintű integrációs tesztekhez lett tervezve. Egységtesztekhez a hagyományos keretrendszerek (JUnit, pytest, Jest) hatékonyabbak és megfelelőbbek.

Hogyan kezdjem el a Gherkin használatát a csapatomban?

A legjobb módja az, ha egy egyszerű, jól ismert funkcióval kezdi. Tartson egy Three Amigos munkamenetet, ahol közösen megírják az első forgatókönyveket. Implementálja a step definition-öket és futtassa le a teszteket. A csapat fokozatosan fogja elsajátítani a Gherkin stílust és a BDD gondolkodásmódot.