BDD (Behavior Driven Development) är en metod som populariserades av Dan North år 2003. Den bygger vidare på och kompletterar TDD (Test Driven Development).
BDD togs fram just för att hantera vanliga problem kring specifikationer i agila projekt:
Det saknas en formell beskrivning av kontexten
Specifikationer kan tolkas olika beroende på roll eller person
Specifikationerna är inte alltid uppdaterade
BDD är därför en agil metod som syftar till att synkronisera alla som är involverade i utvecklingen av en funktion, så att man har en gemensam förståelse för vad som faktiskt ska byggas. Målet är att utforma acceptanstester som illustrerar beteendet för en funktion, med hjälp av exempelvis 3 amigos-möten eller example mapping. BDD sker generellt i tre steg - upptäckt, formulering och automatisering.
De inblandade rollerna (t.ex. produktägare, utvecklare och testare) samarbetar för att ta fram konkreta exempel som visar hur funktionen ska bete sig – det är upptäcktsfasen, ofta i form av ett 3 amigos-möte. Här skapas en gemensam förståelse för behovet, och man skriver scenarier för att bekräfta att alla acceptanskriterier uppfylls.
Exemplen formuleras i ett gemensamt språk, Gherkin, som är enkelt att förstå för olika typer av roller. Gherkin gör det möjligt att skriva strukturerade tester i ett naturligt språk, med tydlig syntax:
GIVEN ett visst sammanhang, WHEN en åtgärd utförs, THEN uppstår ett resultat 1 AND ett resultat 2.
Denna strukturerade beskrivning av beteendet kan sedan användas i ett verktyg som Cucumber, vilket tolkar Gherkin-språket och kör automatiserade acceptanstester utifrån dessa exempel. Det är automatiseringsfasen.
BDD används idag i många företag för att testa funktionalitet i nära samarbete med verksamheten. Men trots att syftet är att skapa en gemensam förståelse, finns det många missuppfattningar som kan leda till att man använder BDD på fel sätt.
BDD reduceras till testautomatisering
När BDD enbart ses som ett sätt att automatisera tester tappar man den verkliga styrkan – att alla inblandade får samma bild av vad som förväntas.
Innan sprinten börjar bör BDD-praktiken fokusera på upptäckt - att säkra en gemensam förståelse av kravet bland alla involverade. Denna förståelse formuleras i form av exempel, acceptanskriterier och acceptansscenarier, som därefter används i verktyg för att automatisera testerna.
Att följa dessa steg hjälper team att undvika BDD-fallgropar och framför allt att undvika den begreppsförvirring som ofta råder kring vad BDD faktiskt är.