BDD-riktlinjer och bästa praxis

BDD (Behavior Driven Development) är en metod för att utveckla programvara genom kontinuerlig exempelbaserat kommunikation mellan utvecklare, kvalitetsbedömningar och BA. I den här artikeln diskuterar vi några bästa metoder för BDD för att få mest nytta.

Mer än någonting annat är det primära syftet med BDD-metoden att uppmuntra kommunikation mellan projektets intressenter så att sammanhanget för varje funktion förstås korrekt av alla medlemmar i teamet (dvs. delad förståelse) innan utvecklingsarbetet startar. Detta hjälper till att identifiera nyckelscenarier för varje berättelse och eliminera oklarheter från kraven.

I BDD kallas exempel för scenarier. Scenarier är strukturerade kring Kontext-åtgärd-resultat mönster och är skrivna i ett speciellt format som kallas Gurka .


Scenarierna är ett sätt att förklara (på engelska) hur en viss funktion ska bete sig i olika situationer eller med olika ingångsparametrar.

Eftersom Gherkin är strukturell fungerar den både som specifikation och inmatning i automatiserade tester, därav namnet 'Executable Specifications'.


Vad är en funktionsfil och vad innehåller den

Funktionsfiler är textfiler med .funktion tillägg, som kan öppnas av vilken textredigerare som helst och kan läsas av alla BDD-medvetna verktyg, såsom Gurka, JBehave eller Behat.

Funktionsfiler bör börja med funktionens sammanhang (vilket i huvudsak är historien), följt av minst ett scenario i följande format

Funktion: En del kortfattad men beskrivande text av vad som önskas

För att förverkliga ett namngivet affärsvärde
Som en uttrycklig systemaktör
Jag vill få ett positivt resultat som främjar målet


Scenario: Någon bestämbar affärssituation

Givet viss förutsättning
Och några andra förutsättningar
När någon handling av skådespelaren
Och några andra åtgärder
Och ännu en åtgärd
Då uppnås något testbart resultat
Och något annat vi kan kontrollera händer också

Scenarier i funktionsfiler bör fokusera på 'vad' snarare än 'hur'. Scenarierna bör vara kortfattade och till punkten, så att läsaren snabbt kan förstå testets avsikt utan att behöva läsa många irrelevanta steg.

Varför ska vi skriva funktionsfiler

Som nämnts tidigare är det främsta syftet med BDD-metoden att uppmuntra kommunikation mellan leveransgruppen. Syftet med funktionsfilerna är att dokumentera scenarierna som diskuterats för att ge en indikation på hur mycket arbete som är involverat i att leverera funktionen. Funktionsfilerna är också drivrutinerna för de automatiska testerna. Funktionsfiler fungerar också som en definition av gjort (DoD), vilket innebär att när alla scenarier har implementerats och testats framgångsrikt kan vi markera historien som klar.


Vem ska skriva funktionsfiler

Det spelar ingen roll vem som faktiskt skriver / skriver in funktionsfilerna, det kan vara vilken som helst medlem i leveransgruppen, men innehållet (scenarier) som diskuteras av en trio Dev-QA-BA är den väsentliga delen av funktionen filer. Att få den gemensamma gemensamma förståelsen för funktionen är nyckelelementet.

När ska funktionsfiler skrivas

Funktionsfiler bör skrivas under berättelsens grooming-sessioner där detaljerna i varje berättelse diskuteras. Funktionsfiler som innehåller scenarier bör skrivas innan utvecklingen startar så att utvecklare såväl som QA har en klar förståelse för avsikten med historien. Det bör finnas en gemensam förståelse för historien. Scenarierna fungerar som krav för utveckling.

Var ska funktionsfiler förvaras

Det borde finnas en sanningskälla som fungerar både som specifikation och automatiserad körning, därför bör den förvaras någonstans där varje medlem i teamet har enkel åtkomst.

Med detta sagt, eftersom funktionsfilerna är drivrutinerna för de automatiska testerna, bör de helst förvaras i källkontrollsystemet (GitHub) så att eventuella uppdateringar av funktionsfilerna omedelbart reflekteras över i testerna.


För icke-tekniska medlemmar som inte har erfarenhet av Git kan vi alltid köra en torrkörning av funktionsfilerna som sedan skickar ut listan över alla befintliga scenarier utan att faktiskt utöva funktionsfilerna.

Hur ska vi skriva funktionsfiler

Det finns vanligtvis två sätt att skriva funktionsfiler - imperativt och deklarativt

Nödvändigt stil för att skriva en funktionsfil, är mycket detaljerad, innehåller detaljer på låg nivå och för mycket information.

Fördelar: den som läser funktionsfilen kan följa steg för steg


Nackdelar: På grund av för mycket detaljer kan läsaren förlora historiens poäng och testerna. Funktionsfilen blir för stor, svår att underhålla och kommer sannolikt att misslyckas på grund av UI-uppdateringar.

Deklarativ stilen för att skriva en funktionsfil är kortfattad och innehåller endast relevant information om historien.

Fördelar: Den deklarativa stilen är mer läsbar eftersom den innehåller färre steg i scenariot. Läsaren kan lätt förstå testets omfattning och snabbt identifiera om några viktiga element saknas.