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/