Vývoj založený na chování - Behavior-driven development

V softwarovém inženýrství je vývoj řízený chováním ( BDD ) agilní proces vývoje softwaru, který podporuje spolupráci mezi vývojáři, testery zajištění kvality a zástupci zákazníků v softwarovém projektu. Vyzývá týmy, aby pomocí konverzace a konkrétních příkladů formalizovaly společné chápání toho, jak by se aplikace měla chovat. Vyplynulo to z testovaného vývoje (TDD). Vývoj založený na chování kombinuje obecné techniky a principy TDD s nápady z návrhů řízených doménami a objektově orientovaných analýz a návrhů, které poskytují týmům pro vývoj a správu softwaru sdílené nástroje a společný proces pro spolupráci na vývoji softwaru.

Ačkoli BDD je v zásadě myšlenkou toho, jak by měl být vývoj softwaru řízen jak obchodními zájmy, tak technickým vhledem, praxe BDD předpokládá použití specializovaných softwarových nástrojů na podporu procesu vývoje. Ačkoli jsou tyto nástroje často vyvíjeny speciálně pro použití v projektech BDD, lze je považovat za specializované formy nástrojů, které podporují vývoj řízený testy. Nástroje slouží k přidání automatizace do všudypřítomného jazyka, který je ústředním tématem BDD.

BDD je do značné míry usnadněno používáním jednoduchého jazyka specifického pro danou doménu (DSL) pomocí konstruktů v přirozeném jazyce (např. Anglické věty), které mohou vyjádřit chování a očekávané výsledky. Testovací skripty jsou již dlouho oblíbenou aplikací DSL s různým stupněm propracovanosti. BDD je považováno za efektivní technickou praxi, zvláště když je „problémový prostor“ obchodního problému k řešení složitý.

Dějiny

Vývoj založený na chování je rozšířením vývoje zaměřeného na testování, vývojový proces, který využívá jednoduchou DSL. Tyto DSL převádějí strukturované příkazy v přirozeném jazyce na spustitelné testy. Výsledkem je užší vztah k kritériím přijetí pro danou funkci a testy použité k ověření této funkce. Jde tedy o přirozené rozšíření testování TDD obecně.

BDD se zaměřuje na:

• Kde začít v procesu
• Co testovat a co netestovat
• Kolik otestovat najednou
• Jak nazvat testy
• Jak pochopit, proč test selže

BDD ve své podstatě spočívá v přehodnocení přístupu k testování jednotek a akceptačním testování, aby se předešlo problémům, které přirozeně vznikají. Například BDD navrhuje, aby názvy testů jednotek byly celé věty začínající podmíněným slovesem (například „mělo by“ v angličtině) a měly by být psány v pořadí podle obchodní hodnoty. Akceptační testy by měly být psány pomocí standardního agilního rámce uživatelského příběhu : „Být [rolí / hercem / zainteresovanou stranou] Chci, aby [vlastnost / schopnost] přinesla [výhodu]“. Kritéria přijetí by měla být napsána z hlediska scénářů a implementována ve třídách: Vzhledem k [počáteční kontext], když [událost nastane], [zajistit určité výsledky] .

Počínaje tímto bodem mnozí lidé vyvinuli rámce BDD v průběhu několika let, až jej nakonec vytvořili jako rámec komunikace a spolupráce pro vývojáře, QA a netechnické nebo obchodní účastníky softwarového projektu. Během „Agilních specifikací, BDD a Testing eXchange“ v listopadu 2009 v Londýně poskytl Dan North následující popis BDD:

BDD je druhá generace, out-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile metodologie. Popisuje cyklus interakcí s přesně definovanými výstupy, jejichž výsledkem je dodání funkčního a testovaného softwaru, na kterém záleží.

Během rozhovoru s Danem Northem na konferenci GOTO v roce 2013 definovala Liz Keogh BDD jako:

Používá příklady k promluvení o tom, jak se aplikace chová ... A vede rozhovory o těchto příkladech.

Dan North vytvořil BDD framework, JBehave , následovaný BDD frameworkem na úrovni příběhu s názvem RBehave, který byl později integrován do projektu RSpec . On také pracoval s Davidem Chelimsky, Aslak Hellesøy a další na vývoji RSpec a také psát "The RSpec Book: Behavior Driven Development with RSpec, Cucumber, and Friends". První rámec založený na příbězích v RSpec byl později nahrazen Cucumberem, který vyvinul hlavně Aslak Hellesøy . Capybara , která je součástí testovacího rámce Cucumber, je jeden takový webový software pro automatizaci testů.

Principy BDD

Test-driven development je metodika vývoje softwaru, která v podstatě uvádí, že pro každou jednotku softwaru musí vývojář softwaru:

• nejdříve definujte testovací sadu pro jednotku ;
• aby testy selhaly;
• poté jednotku implementujte;
• Nakonec ověřte, že implementace jednotky způsobí, že testy uspějí.

Tato definice je poněkud nespecifická v tom, že umožňuje testy, pokud jde o požadavky na software na vysoké úrovni, technické podrobnosti na nízké úrovni nebo cokoli mezi tím. Jedním ze způsobů, jak se na BDD dívat, je tedy to, že jde o pokračující vývoj TDD, který umožňuje konkrétnější volby než TDD.

Vývoj založený na chování určuje, že testy jakékoli jednotky softwaru by měly být specifikovány z hlediska požadovaného chování jednotky. Půjčením od agilního vývoje softwaru se v tomto případě „požadované chování“ skládá z požadavků stanovených obchodem - tj. Z požadovaného chování, které má obchodní hodnotu pro jakýkoli subjekt, který zadal stavbu softwarové jednotky. V praxi BDD se to označuje jako BDD jako aktivita „zvenčí“.

Specifikace chování

Po této základní volbě se druhá volba provedená BDD týká toho, jak by mělo být specifikováno požadované chování. V této oblasti se BDD rozhodlo použít pro formování chování poloformální formát, který je vypůjčený ze specifikací příběhů uživatelů z oblasti objektově orientované analýzy a designu . Scénář aspektem tohoto formátu může být považováno za použití Hoare logika na specifikaci chování softwarových jednotek pomocí domény specifický jazyk situace.

BDD specifikuje, že obchodní analytici a vývojáři by měli v této oblasti spolupracovat a měli by specifikovat chování, pokud jde o příběhy uživatelů, které jsou každý výslovně zapsán do vyhrazeného dokumentu. Každý příběh uživatele by měl nějakým způsobem dodržovat následující strukturu:

Titul

Explicitní název.

Příběh

Krátká úvodní část s následující strukturou:

• Jako : osoba nebo role, která bude mít z funkce užitek;
• Chci : funkci;
• takže : výhoda nebo hodnota funkce.

Kritéria přijatelnosti

Popis každého konkrétního scénáře příběhu s následující strukturou:

• Dáno : počáteční kontext na začátku scénáře, v jedné nebo více klauzulích;
• Kdy : událost, která spustí scénář;
• Pak : očekávaný výsledek v jedné nebo více klauzulích.

BDD nemá žádné formální požadavky na to, jak přesně musí být tyto uživatelské příběhy zapsány, ale trvá na tom, aby každý tým používající BDD přišel s jednoduchým standardizovaným formátem pro psaní uživatelských příběhů, který zahrnuje výše uvedené prvky. V roce 2007 však Dan North navrhl šablonu pro textový formát, který našel široké uplatnění v různých softwarových nástrojích BDD. Velmi krátký příklad tohoto formátu může vypadat takto:

Title: Returns and exchanges go to inventory.

As a store owner,
I want to add items back to inventory when they are returned or exchanged,
so that I can track inventory.

Scenario 1: Items returned for refund should be added to inventory.
Given that a customer previously bought a black sweater from me
and I have three black sweaters in inventory,
when they return the black sweater for a refund,
then I should have four black sweaters in inventory.

Scenario 2: Exchanged items should be returned to inventory.
Given that a customer previously bought a blue garment from me
and I have two blue garments in inventory
and three black garments in inventory,
when they exchange the blue garment for a black garment,
then I should have three blue garments in inventory
and two black garments in inventory.

Scénáře jsou v ideálním případě formulovány spíše deklarativně než imperativně - v obchodním jazyce, bez odkazu na prvky uživatelského rozhraní, prostřednictvím kterých k interakcím dochází.

Tento formát se označuje jako jazyk Gherkin, který má syntaxi podobnou výše uvedenému příkladu. Termín Gherkin , ale je specifické pro okurky , JBehave, salát, chovají a Behatovy softwarových nástrojů.

Specifikace jako všudypřítomný jazyk

Vývoj založený na chování si vypůjčuje koncept všudypřítomného jazyka od návrhu řízeného doménou . Všudypřítomný jazyk je (polo) formální jazyk, který sdílejí všichni členové týmu pro vývoj softwaru - vývojáři softwaru i netechnický personál. Dotyčný jazyk používají a vyvíjejí všichni členové týmu jako běžný prostředek diskuse o doméně daného softwaru. Tímto způsobem se BDD stává prostředkem pro komunikaci mezi všemi různými rolemi v softwarovém projektu.

Společné riziko při vývoji softwaru zahrnuje poruchy komunikace mezi vývojáři a obchodními partnery. BDD používá specifikaci požadovaného chování jako všudypřítomný jazyk pro členy projektového týmu. To je důvod, proč BDD trvá na poloformálním jazyce pro specifikaci chování: určitá formalita je podmínkou pro to, aby byla všudypřítomným jazykem. Mít takový všudypřítomný jazyk navíc vytváří doménový model specifikací, takže o specifikacích lze formálně uvažovat. Tento model je také základem pro různé softwarové nástroje podporující BDD, které jsou k dispozici.

Výše uvedený příklad zavádí příběh uživatele pro vyvíjený softwarový systém. Tento uživatelský příběh identifikuje zúčastněnou stranu, obchodní efekt a obchodní hodnotu. Popisuje také několik scénářů, každý s předběžnou podmínkou, spouštěčem a očekávaným výsledkem. Každá z těchto částí je přesně identifikována formálnější částí jazyka (například termín Given může být považován za klíčové slovo ) a může být proto nějakým způsobem zpracována nástrojem, který rozumí formálním částem všudypřítomného jazyka.

Většina aplikací BDD používá textové DSL a specifikační přístupy. Grafické modelování integračních scénářů se však také úspěšně uplatnilo v praxi, např. Pro účely testování.

Specializovaná podpora nástrojů

Stejně jako testovací postupy založené na testování předpokládá vývoj založený na chování použití specializovaného podpůrného nástroje v projektu. BDD lze chápat jako specifičtější verzi TDD, protože vyžaduje kromě popisu chování v lidsky čitelnějším jazyce dodat nejen testovací kód, ale i samostatný dokument. To vyžaduje dvoustupňový proces pro provádění testů, čtení a analýzu popisů a čtení testovacího kódu a nalezení odpovídající implementace testu k provedení. Díky tomuto procesu je BDD s prací vývojáře o něco pracnější, ale vzhledem k jeho čitelnosti se hodnota těchto dokumentů rozšiřuje i na méně technické publikum, a může tedy sloužit jako komunikační prostředek pro popis požadavků („funkce“) ).

Principy nástrojů

V zásadě je nástrojem podpory BDD testovací rámec pro software, podobně jako nástroje podporující TDD. Avšak tam, kde nástroje TDD mají tendenci být zcela volným formátem v tom, co je povoleno pro specifikaci testů, jsou nástroje BDD spojeny s definicí všudypřítomného jazyka, která byla diskutována dříve.

Jak již bylo řečeno, všudypřítomný jazyk umožňuje obchodním analytikům zapisovat požadavky na chování způsobem, kterému budou rozumět i vývojáři. Principem nástrojů BDD pro podporu je zajistit, aby tyto dokumenty se stejnými požadavky byly přímo spustitelné jako soubor testů. Pokud toho nelze dosáhnout z důvodů souvisejících s technickým nástrojem, který umožňuje provádění specifikací, musí být změněn buď styl psaní behaviorálních požadavků, nebo musí být změněn nástroj. Přesná implementace behaviorálních požadavků se u jednotlivých nástrojů liší, ale agilní praxe přišla s následujícím obecným procesem:

• Nástroj čte dokument se specifikacemi.
• Nástroj přímo rozumí zcela formálním částem všudypřítomného jazyka (například klíčové slovo Given ve výše uvedeném příkladu). Na základě toho nástroj rozdělí každý scénář na smysluplné klauzule.
• Každá jednotlivá klauzule ve scénáři se transformuje do nějakého parametru pro test příběhu uživatele. Tato část vyžaduje vývojářům softwaru práci na konkrétním projektu.
• Rámec poté provede test pro každý scénář s parametry z tohoto scénáře.

Dan North vyvinul řadu rámců, které podporují BDD (včetně JBehave a RBehave ), jejichž provoz je založen na šabloně, kterou navrhl pro záznam příběhů uživatelů. Tyto nástroje používají pro případy použití textový popis a následovalo několik dalších nástrojů (například CBehave). Tento formát však není vyžadován, a proto existují i ​​další nástroje, které používají i jiné formáty. Například Fitnesse (který je postaven na rozhodovacích tabulkách ) byl také použit k zavedení BDD.

Příklady nástrojů

V současnosti se v projektech používá několik různých příkladů softwarových nástrojů BDD pro různé platformy a programovací jazyky.

Možná nejznámější je JBehave, který vyvinuli Dan North, Elizabeth Keogh a několik dalších. Následuje příklad převzatý z tohoto projektu:

Zvažte implementaci Hry o život . Expert na doménu (nebo obchodní analytik) může chtít určit, co by se mělo stát, když někdo nastavuje počáteční konfiguraci herní mřížky. K tomu může chtít uvést příklad řady kroků, které podnikla osoba, která přepíná buňky. Přeskočením narativní části by to mohl udělat napsáním následujícího scénáře do dokumentu ve formátu prostého textu (což je typ vstupního dokumentu, který JBehave čte):

Given a 5 by 5 game
When I toggle the cell at (3, 2)
Then the grid should look like
.....
.....
.....
..X..
.....
When I toggle the cell at (3, 1)
Then the grid should look like
.....
.....
.....
..X..
..X..
When I toggle the cell at (3, 2)
Then the grid should look like
.....
.....
.....
.....
..X..

Tučný tisk není součástí vstupu; je zde uveden, aby ukázal, která slova jsou uznána jako formální jazyk. JBehave rozpoznává pojmy dané (jako předběžná podmínka, která definuje začátek scénáře), kdy (jako spouštěč události) a Then (jako dodatečná podmínka, kterou je třeba ověřit jako výsledek akce, která následuje za spouštěčem). Na základě toho je JBehave schopen číst textový soubor obsahující scénář a analyzovat jej do klauzulí (klauzule o nastavení a poté tři spouštěče událostí s ověřitelnými podmínkami). JBehave poté vezme tyto klauzule a předá je kódu, který je schopen nastavit test, reagovat na spouštěče událostí a ověřit výsledek. Tento kód musí být napsán vývojáři v projektovém týmu (v Javě , protože to je platforma, na které je JBehave založen). V tomto případě může kód vypadat takto:

private Game game;
private StringRenderer renderer;

@Given("a $width by $height game")
public void theGameIsRunning(int width, int height) {
    game = new Game(width, height);
    renderer = new StringRenderer();
    game.setObserver(renderer);
}
    
@When("I toggle the cell at ($column, $row)")
public void iToggleTheCellAt(int column, int row) {
    game.toggleCellAt(column, row);
}

@Then("the grid should look like $grid")
public void theGridShouldLookLike(String grid) {
    assertThat(renderer.asString(), equalTo(grid));
}

Kód má metodu pro každý typ klauzule ve scénáři. JBehave identifikuje, která metoda jde s kterou klauzulí pomocí anotací, a při spuštění scénáře zavolá každou metodu v pořadí. Text v každé klauzuli ve scénáři se předpokládá, aby odpovídala textu šablony uvedené v kódu pro tuto klauzuli (například Vzhledem k tomu, v případě se očekává, že bude následovat klauzule formy „A X Y hry“) . JBehave podporuje porovnávání klauzulí s šablonami a má integrovanou podporu pro vybírání termínů ze šablony a jejich předávání metodám v testovacím kódu jako parametry. Testovací kód poskytuje implementaci pro každý typ klauzule ve scénáři, který interaguje s kódem, který se testuje, a provede test založený na scénáři. V tomto případě:

• Tyto theGameIsRunningmetody reaguje na Vzhledem k tomu doložky podle nastavení počáteční herní mřížky.
• Tyto iToggleTheCellAtmetody reaguje na Kdy klauzule vypalováním z události přepínací popisu uvedeného v bodě.
• Tyto theGridShouldLookLikemetody reaguje na Potom klauzuli porovnáním stav herní sítě k předpokládanému stavu ze scénáře.

Primární funkcí tohoto kódu je být mostem mezi textovým souborem s příběhem a testovaným kódem. Všimněte si, že testovací kód má přístup k testovanému kódu (v tomto případě instance Game) a je ve své podstatě velmi jednoduchý. Testovací kód musí být jednoduchý, jinak by vývojář musel pro své testy psát testy.

A konečně, aby bylo možné spustit testy, JBehave vyžaduje nějaký instalatérský kód, který identifikuje textové soubory, které obsahují scénáře a které Gamedo testovacího kódu vkládají závislosti (například instance ). Tento instalační kód zde není znázorněn, protože se jedná o technický požadavek JBehave a přímo nesouvisí s principem testování ve stylu BDD.

Příběh versus specifikace

Samostatnou podkategorii vývoje založeného na chování tvoří nástroje, které spíše než uživatelské příběhy používají specifikace jako vstupní jazyk. Příkladem tohoto stylu je nástroj RSpec, který také původně vytvořil Dan North. Specifikační nástroje nepoužívají uživatelské příběhy jako vstupní formát pro testovací scénáře, ale spíše používají funkční specifikace pro jednotky, které se testují. Tyto specifikace mají často technickou povahu než uživatelské příběhy a jsou obvykle méně výhodné pro komunikaci s obchodními pracovníky než uživatelské příběhy. Příklad specifikace zásobníku může vypadat takto:

Specification: Stack

When a new stack is created
Then it is empty

When an element is added to the stack
Then that element is at the top of the stack

When a stack has N elements 
And element E is on top of the stack
Then a pop operation returns E
And the new size of the stack is N-1

Taková specifikace může přesně specifikovat chování testované komponenty, ale pro podnikového uživatele je méně smysluplná. Výsledkem je, že testování založené na specifikacích je v praxi BDD vnímáno jako doplněk testování založeného na příběhu a funguje na nižší úrovni. Testování specifikací se často považuje za náhradu testování jednotek ve volném formátu.

Nástroje pro testování specifikací, jako je RSpec a JDave, se v podstatě poněkud liší od nástrojů, jako je JBehave. Vzhledem k tomu, že se tyto nástroje považují za alternativy k základním nástrojům pro testování jednotek, jako je JUnit , mají sklon upustit od oddělení příběhu a testovacího kódu a místo toho upřednostňují vložení specifikace přímo do testovacího kódu. Například test RSpec pro Hashtable může vypadat například takto:

describe Hash do
  let(:hash) { Hash[:hello, 'world'] }

  it { expect(Hash.new).to eq({}) }

  it "hashes the correct information in a key" do
    expect(hash[:hello]).to eq('world')
  end

  it 'includes key' do
    hash.keys.include?(:hello).should be true
  end
end

Tento příklad ukazuje specifikaci v čitelném jazyce vloženou do spustitelného kódu. V tomto případě je volbou nástroje formalizovat jazyk specifikace do jazyka testovacího kódu přidáním metod pojmenovaných ita should. Existuje také koncept předpoklady specifikace - beforečást stanoví předpoklady, na kterých je specifikace založena.

Výsledkem testu bude:

 Hash
   should eq {}
   includes key
   hashes the correct information in a key

Tři Amigové

Three Amigos, označovaný také jako „Specifikační seminář“, je setkání, kde vlastník produktu diskutuje o požadavku ve formě Specifikace příkladem s různými zúčastněnými stranami, jako je QA a vývojový tým. Klíčovým cílem této diskuse je vyvolat konverzaci a identifikovat chybějící specifikace. Tato diskuse také poskytuje platformu pro QA, vývojový tým a vlastníka produktu ke konvergenci a vyslechnutí vzájemné perspektivy, aby obohatili požadavek a také se ujistili, že vytvářejí správný produkt.

Tři Amigové jsou

• Obchod - Role obchodního uživatele je pouze definovat problém (a ne se pustit do navrhování řešení)
• Vývoj - Role vývojářů zahrnuje navrhování způsobů řešení problému
• Testování - Úkolem testerů je zpochybnit řešení, vyvolat tolik různých možností pro útoky mozků prostřednictvím scénářů typu „Co-If“ a pomoci zpřesnit řešení problému.

Viz také

• Specifikace příkladem
• Behat (rámec PHP)
• Rámec cynefinů
• Concordion (Java framework)
• Měřidlo (software)
• Jasmine (rámec testování JavaScriptu)
• Squish GUI Tester (BDD GUI Testing Tool for JavaScript, Python, Perl, Ruby and Tcl)
• Případ použití

Reference