A BDD csapdájában

Igen népszerű a BDD - Behaviour Driven Development. Jellemzően azt gondolják, hogy a BDD egy tesztautomatizálási módszer, valójában nem teljesen az, sőt...

Sok a félreértés körülötte, ebből fakadóan gyorsan el lehet veszni egy BDD bevezetésben.

A BDD valójában nem is tesztelőknek készült. Kitalálója Dan North. Dan kereste az a megfelelő módszert, amivel a üzlet, fejlesztő és a tesztelő (továbbiakban hívjuk Csapatnak) jobban meg tudja érteni, hogy mit kell fejleszteni.

A BDD alapvetően 2 fázisból áll:

1. Példák létrehozása, hogyan fogalmazunk meg egyszerűen, mindenki számára érthetően a rendszer tervezett működését (ami egyben a tesztesetek alapjai is lehet)
2. Hogyan formalizáljuk a megírt példákat, hogy az könnyen automatizálható tesztesetek legyenek

Jellemző, hogy ez utóbbit értik a BDD alatt, amitől viszont esélyes, hogy nem megfelelő lesz a módszer alkalmazása.

Példák létrehozása, cél a közös megértés

Első körben a csapatnak össze kell gyűjtenie azokat az tipikus használati példákat, amelyek a legjellemzőbbek:

• A rendszert leginkább leíró használati példákat tartalmazza
• A megfogalmazás mindenki számára egyértelmű
• Konkrét adatokat tartalmaz

Példa: Sütemény rendelő web oldal tipikus használata:

Torta megrendelés feladása

Példa 1. Tilda néni egy szép tortát szeretne rendelni az unokája születésnapjára, ehhez

• Az oldalon kiválasztja a 12 szeletes gesztenye tortát
• Kér kiegészítőket: 1 óriási csillagszórót
• Kiválasztja a szállítási dátumot: október 26, és jóváhagyja
• Bankkártyával kifizetésre kerül 25€
• Tilda néni kap egy visszaigazolást emailben

Példa 2. Tilda néni kénytelen módosítani a szállítási időpontot, (mert a család átszervezte a születésnapot)

A szállítás előtt 2 nappal még lehet módosítani !

• Tilda néni módosítja az időpontot október 29-re
• Tilda néni kap egy visszaigazolást emailben
• Mit rendelt, mennyit fizetett, mikor szállítják a tortát

Figyelem: a példákat nem kell Gherkin szintaxisban leírni, az majd a formalizálás része lesz!

A példák összegyűjtése segíti a Csapat közös megértését! Nem kell minden példát összegyűjteni, csak azokat, amelyek jól leírják a rendszer tipikus működését.

Ezek a példák egyben az alapvető tesztesetek illetve elfogadási feltételek (Acceptance Criteria) is.

Gherkin forma:

• Given - Adott: a forgatókönyv elején, egy vagy több záradékban szereplő kezdeti környezet;
• When - Mikor: a forgatókönyvet kiváltó esemény;
• Then - Ezután: a várt eredmény, egy vagy több záradékban

Formalizálás = automatizálás

A példák összeállítása után jöhet a formalizálás. Gherkin formába át kell írni a példákat az automatizáláshoz. Fontos, hogy a fejlesztővel közösen kell összerakni a formalizált példákat, mert a BDD tesztek mögé már programrészek hívását kell beilleszteni, azaz alapvető, hogy a kialakított Gherkin mondatok alkalmazkodjanak a programkód struktúrájához, ezért a Gherkin mondatok eltér(het)nek a Példában megfogalmazottól.

A Gherkin formában megadott tesztesetek már futtathatók automatizálva. Jellemzően a service tesztek kialakítására szolgál, kevésbé javalt UI tesztek írására a BDD!

Az igazság…

Tegyük tisztába! A BDD egy specifikációs módszertan, ami segít a közös nyelv megteremtésében és másodsorban jelent automatizálási lehetőséget. Az első nélkül a második nem működik!

Amire érdemes figyelni a BDD használata során:

• Úgy tekintsünk rá, hogy a BDD a specifikációt támogató módszer és nem tesztautomatizálás!
• Válasszuk külön a példák létrehozását illetve a formalizálást (Gherkin szintaxisba átírás)!
• A BDD a tesztautomatizálásban segít, de nem váltja ki a teljes tesztautomatizálást (lásd: tesztautomatizálási piramis: UI tesztek - service tesztek - unit tesztek)

Amit kerüljünk el

A BDD alkalmazásnál érdemes az alábbiakra fgyelni:

1. Nem biztos, hogy jó az, ha az üzlettől már eleve Gherkin formában várjuk a specifikációt:

• az üzlet számára sem feltétlenül komfortos Gherkin nyelven történő írás
• esélyes, hogy rosszul fogják alkalmazni
• a fejlesztők nehezen fogják átkódolni

2. A tipikus példákat automatizáljuk (=regressziós tesztek), különben túlburjánzó automatizált tesztjeink lesznek

3. Ne UI tesztekre használjuk, hanem a gyorsan végrehajtható, kevésbé sérülékeny service tesztekre

… és akkor miért is Behaviour Driven?

Mert a BDD-vel a legjellemzőbb programhasználati viselkedést írhatjuk le, ami nagyban hozzájárul ahhoz, hogy a Csapat tagjai értsék, milyen alkalmazást kell létrehozni, mit kell tesztelni.

További infók, forrás: https://dannorth.net/introducing-bdd/