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:
- 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)
- 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/