BDD (förkortat från engelska Behaviour-driven development , bokstavligen " utveckling genom beteende ") är en metod för mjukvaruutveckling som är en utlöpare av den testdrivna utvecklingsmetoden (TDD).
Huvudidén med denna metod är kombinationen av rent tekniska intressen och affärsintressen i utvecklingsprocessen, vilket gör att ledningspersonal och programmerare kan tala samma språk. För kommunikation mellan dessa grupper av personal används ett domänspecifikt språk , som är baserat på naturliga språkkonstruktioner som är förståeliga för en icke-specialist, vanligtvis uttrycker beteendet hos en mjukvaruprodukt och förväntade resultat.
Man tror att detta tillvägagångssätt är effektivt när ämnesområdet som mjukvaruprodukten verkar inom beskrivs på ett mycket komplext sätt.
BDD-metodik är en förlängning av TDD i den meningen att innan du skriver något test måste du först beskriva det önskade resultatet från den tillagda funktionaliteten på ett domänspecifikt språk. Efter att detta är gjort översätts konstruktionerna av detta språk av specialister eller speciell programvara till en testbeskrivning.
BDD fokuserar på följande frågor:
Baserat på dessa frågor kräver BDD att testnamn ska vara hela meningar som börjar med ett verb i konjunktiven och följer affärsmålen. Acceptanstestbeskrivningar bör skrivas på ett flexibelt användarberättelsespråk, t.ex.
Som en [roll av en vars affärsintressen betjänas] vill jag [beskriva funktionaliteten så som den ska fungera] för att [beskriva fördelen].
Acceptanskriterierna ska beskrivas i termer av ett scenario som användaren implementerar för att uppnå resultatet.
Som redan nämnts måste tester för en mjukvara beskrivas i termer av det önskade beteendet hos den programmerbara enheten. Önskat beteende avser här ett som är av värde för verksamheten. Beskrivningen av det önskade beteendet ges med hjälp av en beteendespecifikation .
Beteendespecifikationen är konstruerad i en semi-formell form. För närvarande har följande struktur etablerats i praktiken av BDD:
BDD tillhandahåller inga formella regler, men insisterar på att en begränsad standarduppsättning fraser ska användas som skulle inkludera alla delar av en beteendespecifikation. 2007 föreslog Dan North en specifikationsmall som blev populär och blev känd som Gherkin- språket [1] [2] .
De grundläggande fraserna i Gherkin-språket presenteras i följande tabell.
| Nyckelord på engelska | anpassning till ryska språket | Beskrivning |
|---|---|---|
| Berättelse ( Feature [3] ) |
Berättelse | Varje ny specifikation börjar med detta nyckelord följt av ett kolon i konjunktivformen av berättelsens namn. |
| Som en | Hur (i en roll) | Rollen för den person i affärsmodellen som är intresserad av denna funktionalitet. |
| För att | Att uppnå | Kortfattat, vad är personens mål. |
| jag vill | jag vill | Beskriv kort slutresultatet. |
| Scenario | Scenario | Varje scenario av en berättelse börjar med detta ord, varefter målet för scenariot skrivs i konjunktiv form, åtskilda av ett kolon. Om det finns flera scenarier i en berättelse, bör dess ordningsnummer skrivas efter nyckelordet. |
| Given | Given | Initialtillstånd. Om det finns flera initiala villkor läggs varje nytt villkor till från en ny rad med hjälp av nyckelordet And. |
| När | När ( obs : något händer) | Händelsen som utlöser det här skriptet. Om händelsen inte kan avslöjas i en mening, avslöjas alla efterföljande detaljer genom nyckelorden Och och Men. |
| Sedan | Sedan | Resultatet som användaren så småningom bör observera. Om resultatet inte kan avslöjas i en mening, avslöjas alla efterföljande detaljer genom nyckelorden Och och Men. |
| Och | Och | Hjälpord, analog till konjunktion . |
| Men | Men | Hjälpord, analog till negation . |
Följande exempel visar en beteendespecifikation som använder Gherkin-språket.
| Berättelse: Returer går till lager Som butiksägare För att hålla koll på lagret vill jag lägga tillbaka varor i lager när de returneras. Scenario 1 : Återbetalade varor ska returneras till lager med tanke på att en kund tidigare köpt en svart tröja av mig Och jag har tre svarta tröjor i lager. När de lämnar tillbaka den svarta tröjan för återbetalning Då borde jag ha fyra svarta tröjor i lager. Scenario 2 : Ersatta artiklar bör returneras till lager Med tanke på att en kund tidigare köpt ett blått plagg av mig Och jag har två blå plagg i lager Och tre svarta plagg i lager. När de lämnar tillbaka det blå plagget för ersättning i svart Då borde jag ha tre blå plagg i lager Och två svarta plagg i lager. | Historik: Returnerad vara måste förvaras i lager Som butiksägare För att hålla reda på varulagret i lagret vill jag återställa register över varor som returneras till lagret. Scenario 1 : Returnerade varor måste läggas i lager Med tanke på att en kund tidigare köpt en svart tröja av mig OCH jag redan har tre identiska i lager. När kunden returnerar den köpta tröjan Då ska jag se att det nu finns 4 svarta tröjor i lager. Scenario 2 : Ersatta artiklar måste returneras till lagret Med tanke på att en kund köpt ett blått plagg av mig OCH jag har två av dessa artiklar i blått OCH tre artiklar i svart på mitt lager. När en kund returnerar ett blått plagg som ska ersättas med ett liknande men svart Då ska jag se att det nu finns tre artiklar i lager för det blå plagget OCH två artiklar för det svarta plagget. |
Det semiformella beteendespecifikationsformatet kräver användning av en begränsad uppsättning förslag som ledningspersonal och utvecklare måste komma överens om i förväg. Baserat på detta byggs ramverk för att stödja BDD enligt följande principer:
Ramverk som JBehave och RBehave, som är baserade på Gherkin-språket, bygger på denna princip. Vissa ramverk är byggda på liknande sätt, som CBehave och Cucumber.
Anta att vi utvecklar en motor för spelet "Life" och vi behöver lägga till möjligheten att initialt placera levande celler på fältet. Anta att när användaren väljer någon ledig punkt i fältet, visas en levande cell på den. Om användaren väljer en fältpunkt som redan är upptagen av en cell, försvinner cellen och fältpunkten blir ledig. Fältkoordinaterna anges i formatet (x,y), där x är det horisontella punktnumret och y är det vertikala punktnumret. Referenspunkten för båda koordinaterna börjar från det övre vänstra hörnet, från en.
Om vi för enkelhets skull utelämnar beskrivningen av beteendespecifikationen kan vi skriva ett sådant skript i Gherkin.
Givet ett 5 gånger 5 spel När jag växlar cellen vid ( 3 , 4 ) Då ska rutnätet se ut som ..... ..... ..... ..X.. ..... När jag växla cellen vid ( 3 , 5 ) Då ska rutnätet se ut som ..... ..... ..... ..X.. ..X.. När jag växlar cellen vid ( 3 , 4 ) ) Då ska rutnätet se ut som ..... ..... ..... ..... ..X..JBehave-ramverket är skrivet i Java, så tester översätts till Java-kod. För JBehave-ramverket skickas detta skript som en vanlig textfil, som läses rad för rad. Allt en utvecklare behöver är att tillhandahålla funktioner som JBehave ska anropa när den hoppar till nästa rad. Till exempel kan en testimplementering se ut så här:
privat spelspel ; _ privat StringRenderer ; _ @Given ( "ett $width by $height-spel" ) public void theGameIsRunning ( int width , int height ) { game = new Game ( width , height ); renderer = new StringRenderer (); spel . setObserver ( renderare ); } @When ( "Jag växlar cellen vid ($column, $row)" ) public void iToggleTheCellAt ( int kolumn , int rad ) { game . toggleCellAt ( kolumn , rad ); } @Then ( "rutnätet ska se ut som $grid" ) public void theGridShouldLookLike ( String grid ) { assertThat ( renderer . asString (), equalTo ( grid )); }För att entydigt mappa en funktion till ett Gherkin-förslag används Java-kommentarer, som tillhandahålls av JBehave-ramverket. Till exempel när motorns parser når någon av meningarna som
När jag växlar cellen vid (n, n)JBehave-motorn kommer att beräkna från anteckningen att metoden måste anropas
void iToggleTheCellAt ( int kolumn , int rad )dessutom är anteckningen skriven på ett sådant sätt att motorn "förstår" att vissa delar av meningen måste fångas och skickas till funktionen som input (i detta exempel är dessa koordinaterna för fältpunkten). Därefter anropar funktionen funktionerna i själva "Life"-spelet, och utvecklaren kontrollerar spelmotorns beteende med de vanliga TDD-verktygen.
C/C++
|
Java
|