BDD (zkráceně z anglického Behavior-driven development , doslova „ vývoj prostřednictvím chování “) je metodika vývoje softwaru, která je odnoží metodologie vývoje řízeného testováním (TDD).
Hlavní myšlenkou této metodiky je kombinace čistě technických zájmů a obchodních zájmů v procesu vývoje, což umožňuje manažerům a programátorům mluvit stejným jazykem. Pro komunikaci mezi těmito skupinami pracovníků se používá doménově specifický jazyk , který je založen na konstrukcích přirozeného jazyka, které jsou srozumitelné i pro laika, obvykle vyjadřující chování softwarového produktu a očekávané výsledky.
Předpokládá se, že tento přístup je účinný, když předmětná oblast, ve které softwarový produkt působí, je popsána velmi složitým způsobem.
Metodologie BDD je rozšířením TDD v tom smyslu, že před napsáním jakéhokoli testu musíte nejprve popsat požadovaný výsledek z přidané funkcionality v jazyce specifickém pro doménu. Poté jsou konstrukce tohoto jazyka přeloženy odborníky nebo speciálním softwarem do testovacího popisu.
BDD se zaměřuje na následující otázky:
Na základě těchto otázek BDD vyžaduje, aby názvy testů byly celé věty, které začínají slovesem v konjunktivu a sledují obchodní cíle. Popisy akceptačních testů by měly být napsány ve flexibilním jazyce uživatelského příběhu, např.
Jako [role toho, jehož obchodním zájmům slouží] chci [popsat funkci tak, jak by měla fungovat], abych [popsal přínos].
Kritéria přijatelnosti musí být popsána z hlediska scénáře, který uživatel implementuje, aby dosáhl výsledku.
Jak již bylo uvedeno, testy pro kus softwaru musí být popsány z hlediska požadovaného chování programovatelného zařízení. Požadované chování zde znamená chování, které má pro podnik hodnotu. Popis požadovaného chování je dán pomocí behaviorální specifikace .
Specifikace chování je konstruována v semi-formální formě. V současné době byla v praxi BDD zavedena následující struktura:
BDD neposkytuje žádná formální pravidla, ale trvá na tom, aby byla použita omezená standardní sada frází, která by zahrnovala všechny prvky specifikace chování. V roce 2007 Dan North navrhl šablonu specifikace, která si získala popularitu a stala se známou jako jazyk okurek [1] [2] .
Základní fráze jazyka okurky jsou uvedeny v následující tabulce.
| Klíčové slovo v angličtině | Adaptace ruského jazyka | Popis |
|---|---|---|
| Příběh ( Funkce [3] ) |
Příběh | Každá nová specifikace začíná tímto klíčovým slovem následovaným dvojtečkou v konjunktivu názvu příběhu. |
| Jako | Jak (v roli) | Role osoby v obchodním modelu, která má o tuto funkcionalitu zájem. |
| V následujících situacích | K dosažení | Stručně řečeno, jaké jsou cíle osoby. |
| chci | chci | Stručně popište konečný výsledek. |
| Scénář | Scénář | Každý scénář jednoho příběhu začíná tímto slovem, za nímž je ve formě konjunktivu napsán cíl scénáře oddělený dvojtečkou. Pokud je v jednom příběhu více scénářů, pak by se za klíčové slovo mělo napsat jeho pořadové číslo. |
| Dáno | Dáno | Výchozí stav. Pokud existuje několik počátečních podmínek, pak se každá nová podmínka přidá z nového řádku pomocí klíčového slova And. |
| Když | Když ( pozn .: něco se stane) | Událost, která spustí tento skript. Pokud událost nelze odhalit jednou větou, pak jsou všechny následující podrobnosti odhaleny prostřednictvím klíčových slov And a But. |
| Pak | Pak | Výsledek, který by měl uživatel nakonec pozorovat. Pokud nelze výsledek odhalit jednou větou, pak jsou všechny následující podrobnosti odhaleny prostřednictvím klíčových slov And a But. |
| A | A | Pomocné klíčové slovo, analogie spojky . |
| Ale | Ale | Pomocné klíčové slovo, analogie negace . |
Následující příklad ukazuje specifikaci chování pomocí jazyka Gherkin.
| Příběh: Vrácení jde do skladu Jako majitel obchodu Abych měl přehled o skladech , chci přidat položky zpět do skladu, když se vrátí. Scénář 1 : Vrácené položky by měly být vráceny na sklad Vzhledem k tomu , že zákazník ode mě dříve koupil černý svetr A já mám na skladě tři černé svetry. Až vrátí černý svetr na vrácení peněz, pak bych měl mít na skladě čtyři černé svetry. Scénář 2 : Vyměněné položky by měly být vráceny na sklad Vzhledem k tomu , že zákazník ode mě dříve koupil modrý oděv A já mám na skladě dva modré oděvy a na skladě tři černé oděvy. Až vrátí modrý oděv na výměnu v černém , pak bych měl mít na skladě tři modré oděvy a dva černé na skladě. | Historie: Vrácené zboží musí být skladem Jako majitel obchodu Abych mohl sledovat zásoby ve skladu , chci obnovit záznamy o položkách, které jsou vráceny do skladu. Scénář 1 : Vrácené zboží musí být umístěno na sklad Vzhledem k tomu, že zákazník ode mě dříve zakoupil černý svetr A já už mám na skladě tři stejné. Když zákazník vrátí zakoupený svetr Pak bych měl vidět, že jsou nyní skladem 4 černé svetry. Scénář 2 : Vyměněné položky musí být vráceny do skladu Vzhledem k tomu, že zákazník ode mě zakoupil modrý oděv A já mám ve svém skladu dvě z těchto položek v modré A tři položky černé. Když zákazník vrátí modrý oděv, který má být nahrazen podobným, ale černým , pak bych viděl, že jsou nyní na skladě tři položky pro modrý oděv A dvě položky pro černý oděv. |
Poloformální formát specifikace chování vyžaduje použití omezeného souboru návrhů, na kterých se musí řídící pracovníci a vývojáři předem dohodnout. Na základě toho jsou rámce pro podporu BDD sestaveny podle následujících principů:
Na tomto principu jsou postaveny frameworky jako JBehave a RBehave, které jsou založeny na jazyce Gherkin. Některé frameworky jsou postaveny podobně, jako CBehave a Cucumber.
Předpokládejme, že vyvíjíme engine pro hru "Life" a potřebujeme přidat schopnost zpočátku umístit živé buňky na hřiště. Předpokládejme, že když uživatel vybere nějaký volný bod pole, objeví se na něm živá buňka. Pokud uživatel vybere bod pole již obsazený buňkou, buňka zmizí a bod pole se uvolní. Souřadnice pole se zadávají ve formátu (x,y), kde x je číslo horizontálního bodu a y je číslo vertikálního bodu. Referenční bod pro obě souřadnice začíná od levého horního rohu, od jedné.
Když pro jednoduchost vynecháme popis specifikace chování, můžeme takový skript napsat v Gherkin.
Při hře 5 x 5 Když přepnu buňku na ( 3 , 4 ) Pak by mřížka měla vypadat jako ..... ..... ..... ..X.. ..... Když přepnout buňku na ( 3 , 5 ) Potom by mřížka měla vypadat jako ..... ..... ..... ..X.. ..X.. Když přepnu buňku na ( 3 , 4 ) ) Potom by mřížka měla vypadat ..... ..... ..... ..... ..X..Rámec JBehave je napsán v Javě, takže testy jsou přeloženy do Java kódu. Pro framework JBehave je tento skript předán jako prostý textový soubor, který se čte řádek po řádku. Vše, co vývojář potřebuje, je poskytnout funkce, které by měl JBehave volat, když skočí na další řádek. Testovací implementace může vypadat například takto:
soukromá hra hra ; private StringRenderer ; _ @Given ( "hra $width by $height" ) public void theGameIsRunning ( int width , int height ) { game = new Game ( width , height ); renderer = new StringRenderer (); hra . setObserver ( renderer ); } @When ( "Přepnu buňku na ($column, $row)" ) public void iToggleTheCellAt ( int column , int row ) { game . toggleCellAt ( sloupec , řádek ); } @Then ( "mřížka by měla vypadat jako $grid" ) public void theGridShouldLookLike ( String grid ) { ClaimThat ( renderer . asString (), equalTo ( grid )); }Aby bylo možné jednoznačně namapovat funkci na návrh Gherkin, používají se Java anotace, které poskytuje framework JBehave. Například, když analyzátor motoru dosáhne některé z vět jako
Když přepnu buňku na (n, n)engine JBehave z anotace vypočítá, že je třeba metodu zavolat
void iToggleTheCellAt ( int sloupec , int řádek )anotace je navíc napsána tak, že engine „rozumí“, že některé části věty je třeba zachytit a předat funkci jako vstup (v tomto příkladu jsou to souřadnice bodu pole). Dále funkce volá funkce samotné hry „Life“ a vývojář kontroluje chování herního enginu pomocí obvyklých nástrojů TDD.
C/C++
|
Jáva
|