BDD: mi ez, viselkedési forgatókönyvek és keretrendszerek

Mi az a BDD?

Behavior-Driven Development — a TDD evolúciója, amelyet Dan North javasolt 2006-ban válaszként a tesztek megfogalmazásának problémájára. A TDD-ben a fejlesztő tesztet ír, de a „mit pontosan teszteljünk?“ kérdés nyitott marad. A BDD megoldja ezt a problémát azzal, hogy a fókuszt a kód teszteléséről a rendszer viselkedésének leírására helyezi a felhasználó szemszögéből.

A BDD kulcsinnovációja — közös nyelv a projekt összes résztvevője számára. A fejlesztők, tesztelők, elemzők és megrendelők egységes nyelven vitatják meg a forgatókönyveket, amely egyben egy végrehajtható teszt is. Ez megszünteti a klasszikus „romlott telefon“ problémáját, amikor a követelmények elveszítik értelmüket az elemzőtől a fejlesztőhöz való továbbításkor.

A BDD kialakulásának története

Dan North 2006-ban fogalmazta meg a BDD-t a „Introducing BDD“ című cikkében a ThinkCode blogon. Észrevette, hogy a TDD-ben a tesztek neveit gyakran implementációs kifejezésekkel („testAddUser“) fogalmazzák meg, nem pedig viselkedési kifejezésekkel („user should be able to register with email“). A BDD a „test“ szót „should“-ra, az „assert“-et „expect“-re cserélte, áthelyezve a fókuszt a felhasználó számára nyújtott értékre.

BDD mint kommunikációs gyakorlat

A Cambridge University (2021) kutatása szerint a BDD-forgatókönyveket a megrendelővel való kommunikációban használó projektek 35%-kal csökkentik a követelmények hibáinak számát a hagyományos szöveges dokumentumokban lévő specifikációkhoz képest. A végrehajtható forgatókönyvek nem teszik lehetővé kétértelmű megfogalmazásokat — minden Given-When-Then vagy végrehajtódik, vagy nem.

Gherkin nyelv és szintaxis

Gherkin — egy doménspecifikus nyelv, amelyet a Cucumber és SpecFlow keretrendszerek használnak a viselkedési forgatókönyvek leírására. A Gherkin behúzásokat és kulcsszavakat használ a forgatókönyvek strukturálására, miközben olvasható marad technikai háttérrel nem rendelkező személyek számára is.

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

Gherkin kulcsszavak

A Gherkin néhány alapvető kulcsszót határoz meg. A Feature leírja a funkcionalitást, a Scenario — a konkrét forgatókönyvet, a Given — az előfeltételeket, a When — a cselekvést, a Then — a várt eredményt. Ezenkívül az And és a But több feltétel összekapcsolására szolgál.

.feature fájl szerkezete

A Gherkin fájlok .feature kiterjesztéssel rendelkeznek, és Android projektekben a src/test/resources/features/ könyvtárban tárolódnak. Minden fájl egy Feature leírással kezdődik, amelyet egy vagy több Scenario követ. Paraméterezéshez a Scenario Outline Examples táblázatokkal használatos — ez lehetővé teszi ugyanazon forgatókönyv futtatását különböző adatokkal.

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     |

Given-When-Then formátum

Given-When-Then — a forgatókönyvek leírásának strukturális mintája, amelyet a BDD a domain-driven design-ból vett át. Minden forgatókönyv három részből áll: előfeltételek, cselekvés és várt eredmény. Ez a formátum természetesen megfelel az egységtesztelés Arrange-Act-Assert mintájának, de az üzlet számára érthető nyelvet használ.

Given: kontextus

A Given blokk leírja a rendszer állapotát a forgatókönyv megkezdése előtt: milyen adatok léteznek, mely összetevők aktívak, milyen módban működik az alkalmazás. Mobil kontextusban ez lehet „a felhasználó be van jelentkezve“, „a kosár nem üres“ vagy „a készülék offline üzemmódban van“.

When: cselekvés

A When blokk leírja a felhasználó vagy a rendszer által kezdeményezett eseményt: gomb megnyomása, push-értesítés fogadása, szerver válasza. Mobil alkalmazásokban ez gyakran egy ViewModel metódus meghívásának vagy egy UI elem megérintésének felel meg.

Then: eredmény

A Then blokk leírja az állapot várt változását: képernyőváltás, API-hívás, adatbázis frissítése. A Then-ben lévő ellenőrzéseknek mérhetőnek és egyértelműnek kell lenniük — ezek lesznek az állítások a végrehajtható kódban.

BDD és TDD: megközelítések összehasonlítása

A BDD és a TDD gyakran összekeveredik, bár különböző fegyelmi szintek. A TDD — kód szintű tervezési technika: „hogyan írjuk meg a megvalósítást“. A BDD — követelmény szintű specifikációs technika: „mit kell a rendszernek tennie“.

Kölcsönös kiegészítés a projektben

A legjobb mobil projektek a TDD-t az egyes osztályok szintjén (domain réteg) és a BDD-t a forgatókönyvek szintjén (feature réteg) használják. Ez kettős lefedettséget biztosít: a TDD garantálja a megvalósítás helyességét, a BDD — a követelmények megértésének helyességét. A Google belső gyakorlatában a TDD és BDD kombinációját használja Android alkalmazásokhoz, ahogy az Android Testing (2024) dokumentációban szerepel.

BDD eszközök mobilfejlesztéshez

A BDD ökoszisztéma keretrendszereket foglal magában a mobilfejlesztés összes népszerű platformjához és nyelvéhez. Az eszköz kiválasztása a technológiai veremtól és az automatizáltság szintjétől függ.

Cucumber Androidhoz

Cucumber — a legnépszerűbb BDD keretrendszer, amely Gherkin forgatókönyvekkel dolgozik. Android projektekhez a io.cucumber:cucumber-android könyvtárat használják, amely integrálódik az Espresso és Compose Test UI tesztelő eszközökkel. A Cucumber támogatja a Kotlin és Java nyelveket, ami univerzális választássá teszi a mindkét nyelvet használó stúdiók számára.

SpecFlow Xamarinhoz

SpecFlow — BDD keretrendszer a .NET ökoszisztémához, amelyet Xamarin.Forms és .NET MAUI projektekben használnak. A SpecFlow integrálódik az NUnit és xUnit keretrendszerekkel, lépéseit (step definitions) C# nyelven írják. Mobil projektekhez a SpecFlow lehetővé teszi a forgatókönyvek újrafelhasználását az Android és iOS verziók között közös kódbázison.

Quick/Nimble iOS-hez

Az iOS fejlesztéshez Swift nyelven léteznek a Quick és Nimble BDD keretrendszerek. A Quick DSL-t biztosít a forgatókönyvek describe/it stílusú leírásához, a Nimble pedig olvasható szintaxisú matchereket. Bár ezek a keretrendszerek nem használják közvetlenül a Gherkint, megvalósítják a BDD elvét: a viselkedés leírását a teljes csapat számára érthető nyelven.

BDD forgatókönyvek és kód példák

Vizsgáljuk meg a BDD teljes példáját egy Android projektben: rendelési forgatókönyv. Először megírjuk a Gherkin forgatókönyvet, majd — a step definitions Kotlin nyelven.

BDD működési elve: three amigos

A BDD módszertan a three amigos — három szerep: fejlesztő, tesztelő és elemző találkozóján alapul. Ők együtt írják a forgatókönyveket a fejlesztés megkezdése előtt, rögzítve a követelmények közös megértését. Ha a forgatókönyv egyik résztvevőnek sem felel meg — a követelmény félreérthetően van megfogalmazva. Ez a gyakorlat a „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) könyvben van leírva, és kötelező része a BDD folyamatnak érett csapatokban.

Gherkin rendelési forgatókönyv

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 Kotlinban

Step definitions — kód, amely összeköti a Gherkin forgatókönyvet a teszt megvalósításával. Minden lépés egy metódus annotációval, amely megfelel a Gherkin kulcsszónak.

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())
    }
}

Integráció a Cucumber Androiddal

A BDD tesztek futtatásához Android projektben a CucumberAndroidJUnitRunner használatos. Ez beolvassa a .feature fájlokat az erőforrásokból, megtalálja a megfelelő step definitions-okat reguláris kifejezésekkel, és végrehajtja a forgatókönyveket szokásos instrumentális tesztként. Az eredmények a megrendelő számára érthető HTML jelentésben formázódnak.

// 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

A BDD bevezetésének nehézségei mobil projektekben

A BDD bevezetése a mobil fejlesztésbe számos gyakorlati nehézséggel jár. E problémák tudatosítása segít a csapatoknak elkerülni a csalódást és fenntartható BDD folyamatot kiépíteni.

.feature fájlok karbantartása

A fő probléma — deszinkronizáció a Gherkin forgatókönyvek és a termelési kód között. Ha a fejlesztők megváltoztatják az API-t a step definitions frissítése nélkül, a .feature fájlok nem felelnek meg a megvalósításnak. Megoldás — a BDD tesztek futtatása a CI/CD pipeline-ban és zöld státusz kérése a merge requesthez. A „BDD as a gating mechanism“ gyakorlat a Cucumber (2024) dokumentációban van leírva, és ipari szabványnak számít.

BDD tesztek teljesítménye

A Cucumber BDD forgatókönyvei instrumentális teszteken keresztül futnak Android eszközön vagy emulátoron. Ez 10–50-szer lassabb, mint a szokásos egységtesztek a JVM-en. Egyetlen átvételi teszt 20–30 percet is igénybe vehet egy nagy Android alkalmazás esetén. Javasolt a BDD teszteket külön CI feladatba elkülöníteni és éjszaka futtatni, az egységteszteket pedig minden push-kor. Ez a stratégia egyensúlyt teremt a visszajelzés sebessége és a forgatókönyvek lefedettsége között.

Csapat képzése Gherkinre

A BDD-re való áttérés képzést igényel nemcsak a fejlesztők, hanem az elemzők és tesztelők számára is. A Gherkin egyszerű nyelv, de a jó forgatókönyvek írásához gyakorlat kell. A kezdők tipikus hibái: túl hosszú forgatókönyvek (több mint 10 lépés), a Given-When-Then összekeverése, technikai kifejezések használata üzleti forgatókönyvekben. A BDD Academy (2024) szerint a csapatoknak átlagosan 4–6 sprintre van szükségük a BDD forgatókönyvek írásában való érettség eléréséhez.