A BDD (rövidítve az angol Behavior-driven development szóból , szó szerint „ fejlesztés a viselkedésen keresztül ”) egy olyan szoftverfejlesztési módszertan, amely a tesztvezérelt fejlesztési (TDD) módszertanból származik.
Ennek a módszernek a fő gondolata a tisztán technikai és üzleti érdekek ötvözése a fejlesztési folyamatban, lehetővé téve ezáltal, hogy a vezetők és a programozók ugyanazt a nyelvet beszéljék. A személyzet ezen csoportjai közötti kommunikációhoz egy tartomány-specifikus nyelvet használnak , amely a nem szakember számára érthető természetes nyelvi konstrukciókon alapul, és általában egy szoftvertermék viselkedését és az elvárt eredményeket fejezi ki.
Úgy gondolják, hogy ez a megközelítés akkor hatékony, ha a szoftvertermék működési területét nagyon összetett módon írják le.
A BDD módszertan a TDD kiterjesztése abban az értelemben, hogy mielőtt bármilyen tesztet írna, először le kell írnia a hozzáadott funkcionalitás kívánt eredményét egy tartományspecifikus nyelven. Miután ez megtörtént, ennek a nyelvnek a konstrukcióit szakemberek vagy speciális szoftver lefordítják tesztleírásba.
A BDD a következő kérdésekre összpontosít:
E kérdések alapján a BDD megköveteli, hogy a tesztnevek egész mondatok legyenek, amelyek igével kezdődnek a kötőszóban, és követik az üzleti célokat. Az elfogadási tesztek leírásait rugalmas felhasználói sztori nyelven kell megírni, pl.
Mint [olyan szerepkör, akinek üzleti érdekeit szolgálják] szeretném [leírni a funkcionalitást, ahogyan annak működnie kell] annak érdekében, hogy [leírjam az előnyt].
Az elfogadási feltételeket egy olyan forgatókönyv formájában kell leírni, amelyet a felhasználó az eredmény elérése érdekében végrehajt.
Mint már említettük, egy szoftver tesztjét a programozható eszköz kívánt viselkedése alapján kell leírni. A kívánt viselkedés itt olyan viselkedésre vonatkozik, amely értéket képvisel a vállalkozás számára. A kívánt viselkedés leírását viselkedési specifikáció segítségével adjuk meg .
A viselkedési specifikáció félig formális formában van felépítve. Jelenleg a következő struktúra alakult ki a BDD gyakorlatában:
A BDD nem ad semmilyen formális szabályt, de ragaszkodik ahhoz, hogy korlátozott szabványos kifejezéskészletet használjanak, amely magában foglalja a viselkedési specifikáció összes elemét. 2007-ben Dan North egy specifikációs sablont javasolt, amely népszerűvé vált, és uborkanyelvként vált ismertté [1] [2] .
Az uborka nyelv alapvető kifejezéseit a következő táblázat mutatja be.
| Kulcsszó angolul | Orosz nyelvi adaptáció | Leírás |
|---|---|---|
| Történet ( [3] szolgáltatás ) |
Sztori | Minden új specifikáció ezzel a kulcsszóval kezdődik, amelyet kettőspont követ a történet nevének kötőszóban. |
| Mint a | Hogyan (egy szerepben) | Annak a személynek a szerepe az üzleti modellben, akit érdekel ez a funkció. |
| Azért, hogy | Megvalósítani | Röviden, mik a személy céljai. |
| akarok | akarok | Röviden írja le a végeredményt. |
| Forgatókönyv | Forgatókönyv | Egy történet minden forgatókönyve ezzel a szóval kezdődik, majd a forgatókönyv célját aláíró formában, kettősponttal elválasztva írják le. Ha egy történetben több forgatókönyv van, akkor a kulcsszó után annak sorszámát kell írni. |
| Adott | Adott | Kezdeti állapot. Ha több kezdeti feltétel van, akkor minden új feltétel egy új sorból kerül hozzáadásra az És kulcsszó használatával. |
| Mikor | Mikor ( megjegyzés : történik valami) | Az esemény, amely elindítja ezt a szkriptet. Ha az eseményt nem lehet egy mondatban feltárni, akkor minden további részlet az És és a De kulcsszavakon keresztül derül ki. |
| Akkor | Akkor | Az eredmény, amelyet a felhasználónak végül meg kell figyelnie. Ha az eredményt nem lehet egy mondatban felfedni, akkor minden további részlet az És és a De kulcsszavakon keresztül derül ki. |
| És | És | Segédszó, a kötőszó analógja . |
| De | De | Segédszó, a tagadás analógja . |
A következő példa egy viselkedésspecifikációt mutat be a Gherkin nyelv használatával.
| Történet: A visszáru készletre megy Bolttulajdonosként A készlet nyomon követése érdekében szeretném visszahelyezni a készletbe a termékeket, amikor visszaküldik őket. 1. forgatókönyv : A visszatérített tételeket vissza kell raktározni Tekintettel arra , hogy egy ügyfél korábban fekete pulóvert vásárolt tőlem, és három fekete pulóverem van raktáron. Amikor visszaküldik a fekete pulóvert a visszatérítésért , akkor négy fekete pulóvernek kell lennie raktáron. 2. forgatókönyv : A kicserélt cikkeket vissza kell küldeni a készletbe Tekintettel arra , hogy egy ügyfél korábban vásárolt tőlem egy kék ruhát, és két kék ruhadarabom van raktáron, és három fekete ruhadarabom van raktáron. Amikor visszaküldik a kék ruhadarabot fekete cserére, akkor három kék ruhadarabnak kell lennie raktáron és két fekete ruhadarabnak készleten. | Előzmények: A visszaküldött terméket készleten kell tartani Üzlettulajdonosként A raktárban lévő készlet nyomon követéséhez vissza szeretném állítani a raktárba visszaküldött cikkek nyilvántartását. 1. forgatókönyv : A visszaküldött tételeket raktáron kell elhelyezni Tekintettel arra, hogy egy vásárló korábban fekete pulóvert vásárolt tőlem, ÉS már három egyforma van raktáron. Amikor a vásárló visszaküldi a vásárolt pulóvert Akkor látnom kell, hogy most 4 db fekete pulóver van raktáron. 2. forgatókönyv : A kicserélt cikkeket vissza kell küldeni a raktárba Tekintettel arra, hogy egy ügyfél kék ruhát vásárolt tőlem, ÉS ezek közül kettő kék és három fekete cikk van a raktáromban. Amikor a vásárló visszaküld egy kék ruhadarabot, hogy egy hasonlóra, de feketére cserélje ki, akkor látnom kell, hogy a kék ruhadarabból három , a fekete ruhadarabból pedig két cikk van raktáron. |
A félig formális viselkedésspecifikációs formátum korlátozott számú javaslat használatát teszi szükségessé, amelyeket a vezetőknek és a fejlesztőknek előzetesen meg kell állapodniuk. Ennek alapján a BDD támogatására szolgáló keretrendszerek az alábbi elvek szerint épülnek fel:
Az olyan keretrendszerek, mint a JBehave és az RBehave, amelyek a Gherkin nyelven alapulnak, erre az elvre épülnek. Néhány keretrendszer hasonlóan épül fel, például a CBehave és az Cucumber.
Tegyük fel, hogy egy motort fejlesztünk a "Life" játékhoz , és hozzá kell adnunk azt a képességet, hogy először élő sejteket helyezzünk el a pályán. Tegyük fel, hogy amikor a felhasználó kiválaszt egy szabad pontot a mezőben, egy élő cella jelenik meg rajta. Ha a felhasználó olyan mezőpontot választ ki, amelyet egy cella már foglalt, a cella eltűnik, és a mezőpont szabaddá válik. A mező koordinátáit (x,y) formátumban kell megadni, ahol x a vízszintes pont száma, y pedig a függőleges pont száma. Mindkét koordináta referenciapontja a bal felső sarokból, az egyiktől kezdődik.
A viselkedési specifikáció leírását az egyszerűség kedvéért elhagyva írhatunk egy ilyen szkriptet Gherkin nyelven.
Adott egy 5 : 5 -ös játék Amikor átkapcsolom a cellát a ( 3 , 4 ) értéknél, akkor a rácsnak így kell kinéznie: ..... ..... ..... ..X.. ..... Amikor én a cella átváltása a ( 3 , 5 ) pontnál . Ekkor a rácsnak így kell kinéznie ) Ekkor a rácsnak így kell kinéznie: ..... ..... ..... ..... ..X..A JBehave keretrendszer Java nyelven íródott, így a teszteket Java kódra fordítják. A JBehave keretrendszer esetében ez a szkript egyszerű szöveges fájlként kerül átadásra, amelyet soronként olvasnak be. A fejlesztőnek csak olyan függvényeket kell biztosítania, amelyeket a JBehave-nek meg kell hívnia, amikor a következő sorra ugrik. Például egy tesztmegvalósítás így nézhet ki:
privát játék játék ; privát StringRenderer ; _ @Given ( "egy $szélesség x magasság játék" ) public void theGameIsRunning ( int szélesség , int magasság ) { game = new Game ( szélesség , magasság ); renderer = new StringRenderer (); játék . setObserver ( renderer ); } @When ( "Átkapcsolom a cellát itt: ($oszlop, $sor)" ) public void iToggleTheCellAt ( int oszlop , int sor ) { game . toggleCellAt ( oszlop , sor ); } @Then ( "a rácsnak úgy kell kinéznie, mint $rács" ) public void theGridShouldLookLike ( String grid ) { assertThat ( renderer . asString (), egyenlőTo ( grid )); }Egy függvény Gherkin-javaslathoz való egyértelmű leképezéséhez Java annotációkat használnak, amelyeket a JBehave keretrendszer biztosít. Például amikor a motor elemzője eléri a hasonló mondatok bármelyikét
Amikor átkapcsolom a cellát (n, n)a JBehave motor a megjegyzésből kiszámítja, hogy a metódust meg kell hívni
void iToggleTheCellAt ( belső oszlop , belső sor )ráadásul az annotációt úgy írják, hogy a motor „megértse”, hogy a mondat egyes részeit rögzíteni kell és bemenetként át kell adni a függvénynek (ebben a példában ezek a mezőpont koordinátái). Ezután a függvény maga a „Life” játék funkcióit hívja meg, a fejlesztő pedig a szokásos TDD eszközök segítségével ellenőrzi a játékmotor viselkedését.
C/C++
|
Jáva
|