BDD: vad är det, beteendescenarier och ramverk

Vad är BDD?

Behavior-Driven Development — är en evolution av TDD, föreslagen av Dan North 2006 som ett svar på problemet med att formulera tester. I TDD skriver utvecklaren ett test, men frågan „vad exakt ska testas?“ förblir öppen. BDD löser detta problem genom att flytta fokus från kodtestning till att beskriva systemets beteende ur användarens perspektiv.

Den viktigaste innovationen med BDD — gemensamt språk för alla projektdeltagare. Utvecklare, testare, analytiker och kunder diskuterar scenarier på ett enhetligt språk som samtidigt är ett körbart test. Detta eliminerar det klassiska problemet med „trasi telefon“, när krav förlorar sin mening vid överföring från analytiker till utvecklare.

Historia om BDD

Dan North formulerade BDD 2006 i artikeln „Introducing BDD“ på bloggen ThinkCode. Han noterade att testnamn i TDD ofta formuleras i implementeringstermer („testAddUser“), inte i beteendetermer („user should be able to register with email“). BDD ersatte ordet „test“ med „should“ och „assert“ med „expect“, vilket flyttade fokus till värde för användaren.

BDD som kommunikationspraxis

Enligt forskning från Cambridge University (2021) minskar projekt som använder BDD-scenarier i kommunikation med kunden antalet fel i krav med 35% jämfört med traditionella specifikationer i textdokument. Körbara scenarier tillåter inte tvetydiga formuleringar — varje Given-When-Then antingen körs eller inte.

Språket Gherkin och syntax

Gherkin — är ett domänspecifikt språk som används av ramverken Cucumber och SpecFlow för att beskriva beteendescenarier. Gherkin använder indrag och nyckelord för att strukturera scenarier, samtidigt som det förblir läsbart för en person utan teknisk bakgrund.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Gherkins nyckelord

Gherkin definierar flera grundläggande nyckelord. Feature beskriver funktionaliteten, Scenario — det konkreta scenariot, Given — förutsättningarna, When — handlingen, Then — det förväntade resultatet. Dessutom används And och But för att kombinera flera villkor.

Struktur för .feature-fil

Gherkin-filer har tillägget .feature och lagras i katalogen src/test/resources/features/ i Android-projekt. Varje fil börjar med en Feature-beskrivning, följd av ett eller flera Scenario. För parametrisering används Scenario Outline med Examples-tabeller — detta gör det möjligt att köra samma scenario med olika data.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Formatet Given-When-Then

Given-When-Then — är ett strukturellt mönster för att beskriva scenarier, lånat av BDD från domain-driven design. Varje scenario består av tre delar: förutsättningar, handling och förväntat resultat. Detta format motsvarar naturligt Arrange-Act-Assert från enhetstestning, men använder ett språk som är förståeligt för verksamheten.

Given: kontext

Blocket Given beskriver systemets tillstånd före starten av scenariot: vilka data som finns, vilka komponenter som är aktiva, i vilket läge applikationen fungerar. I mobil kontext kan detta vara „användaren är inloggad“, „varukorgen är inte tom“ eller „enheten är i offline-läge“.

When: handling

Blocket When beskriver händelsen som initieras av användaren eller systemet: knapptryckning, mottagande av push-notis, server-svar. I mobila applikationer motsvarar detta ofta anrop av en ViewModel-metod eller tryck på ett UI-element.

Then: resultat

Blocket Then beskriver den förväntade tillståndsförändringen: skärmbyte, API-anrop, databasuppdatering. Kontroller i Then måste vara mätbara och entydiga — de blir påståenden i körbar kod.

BDD och TDD: jämförelse av metoder

BDD och TDD förväxlas ofta, även om de är olika disciplinnivåer. TDD — designteknik på kodnivå: „hur man skriver implementering“. BDD — specifikationsteknik på kravnivå: „vad systemet ska göra“.

Ömsesidig komplettering i projektet

De bästa mobila projekten använder TDD på nivån av enskilda klasser (domain-lager) och BDD på nivån av scenarier (feature-lager). Detta ger dubbel täckning: TDD garanterar korrekt implementering, BDD — korrekt förståelse av kraven. Google använder i sin interna praxis en kombination av TDD och BDD för Android-applikationer, som anges i dokumentationen Android Testing (2024).

BDD-verktyg för mobil utveckling

BDD-ekosystemet omfattar ramverk för alla populära plattformar och språk inom mobil utveckling. Valet av verktyg beror på teknikstacken och automatiseringsnivån.

Cucumber för Android

Cucumber — det populäraste BDD-ramverket som arbetar med Gherkin-scenarier. För Android-projekt används biblioteket io.cucumber:cucumber-android, som integreras med UI-testverktygen Espresso och Compose Test. Cucumber stöder Kotlin och Java, vilket gör det till ett universellt val för studior som använder båda språken.

SpecFlow för Xamarin

SpecFlow — BDD-ramverk för .NET-ekosystemet, som används i Xamarin.Forms och .NET MAUI-projekt. SpecFlow integreras med NUnit och xUnit, och dess steg (step definitions) skrivs i C#. För mobila projekt möjliggör SpecFlow återanvändning av scenarier mellan Android- och iOS-versioner av applikationen på en gemensam kodbas.

Quick/Nimble för iOS

För iOS-utveckling i Swift finns BDD-ramverken Quick och Nimble. Quick tillhandahåller ett DSL för att beskriva scenarier i describe/it-stil, och Nimble — matchers med läsbar syntax. Även om dessa ramverk inte använder Gherkin direkt, implementerar de BDD-principen: beskrivning av beteende på ett språk som är förståeligt för hela teamet.

Exempel på BDD-scenarier och kod

Låt oss titta på ett komplett exempel på BDD i ett Android-projekt: beställningsscenario. Först skriver vi Gherkin-scenariot, sedan — step definitions i Kotlin.

BDD:s arbetsprincip: three amigos

BDD-metodiken bygger på mötet mellan three amigos — tre roller: utvecklare, testare och analytiker. De skriver tillsammans scenarier innan utvecklingen börjar och fastställer en gemensam förståelse av kraven. Om scenariot inte passar någon av de tre deltagarna — betyder det att kravet är formulerat tvetydigt. Denna praxis beskrivs i boken „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) och är en obligatorisk del av BDD-processen i mogna team.

Gherkin-scenario för beställning

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions i Kotlin

Step definitions — kod som kopplar Gherkin-scenariot till testimplementeringen. Varje steg är en metod med en anteckning som motsvarar Gherkins nyckelord.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Integration med Cucumber Android

För att köra BDD-tester i ett Android-projekt används CucumberAndroidJUnitRunner. Den skannar .feature-filer i resurserna, hittar motsvarande step definitions via reguljära uttryck och kör scenarierna som vanliga instrumentella tester. Resultaten formateras i en HTML-rapport som är förståelig för kunden.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Svårigheter med att införa BDD i mobila projekt

Att införa BDD i mobil utveckling är förknippat med ett antal praktiska svårigheter. Medvetenhet om dessa problem hjälper team att undvika besvikelse och bygga en hållbar BDD-process.

Underhåll av .feature-filer

Huvudproblemet — desynkronisering mellan Gherkin-scenarier och produktionskod. Om utvecklare ändrar API utan att uppdatera step definitions, överensstämmer inte .feature-filerna längre med implementeringen. Lösning — köra BDD-tester i CI/CD-pipelinen och kräva grön status för merge request. Praxisen „BDD as a gating mechanism“ beskrivs i Cucumbers dokumentation (2024) och är en standard inom branschen.

Prestanda för BDD-tester

BDD-scenarier i Cucumber körs genom instrumentella tester på en Android-enhet eller emulator. Detta är 10–50 gånger långsammare än vanliga enhetstester på JVM. Ett enda acceptanstest kan ta 20–30 minuter för en stor Android-applikation. Det rekommenderas att separera BDD-tester till ett separat CI-jobb och köra dem på natten, och enhetstester — vid varje push. En sådan strategi balanserar återkopplingshastighet och scenario-täckning.

Teamutbildning i Gherkin

Övergången till BDD kräver utbildning inte bara av utvecklare utan också av analytiker och testare. Gherkin är ett enkelt språk, men att skriva bra scenarier kräver övning. Typiska nybörjarfel: för långa scenarier (mer än 10 steg), blandning av Given-When-Then, användning av tekniska termer i affärsscenarier. Enligt BDD Academy (2024) behöver team i genomsnitt 4–6 sprintar för att uppnå mognad i att skriva BDD-scenarier.