BDD: Nedir, Davranış Senaryoları ve Framework'ler

BDD Nedir?

Behavior-Driven Development, Dan North tarafından 2006 yılında test formülasyonu sorununa bir yanıt olarak önerilen TDD'nin bir evrimidir. TDD'de geliştirici bir test yazar, ancak “tam olarak ne test edilmeli?” sorusu açık kalır. BDD, odağı kod testinden kullanıcı bakış açısıyla sistem davranışını tanımlamaya kaydırarak bu sorunu çözer.

BDD'nin temel yeniliği, tüm proje katılımcıları için ortak bir dil olmasıdır. Geliştiriciler, testçiler, analistler ve müşteriler, aynı zamanda çalıştırılabilir bir test olarak hizmet eden birleşik bir dilde senaryoları tartışır. Bu, analistten geliştiriciye geçerken gereksinimlerin anlamını yitirdiği klasik “bozuk telefon” sorununu ortadan kaldırır.

BDD'nin Ortaya Çıkış Tarihi

Dan North, BDD'yi 2006 yılında ThinkCode blogundaki “Introducing BDD” makalesinde formüle etti. TDD'de test adlarının genellikle davranış terimleriyle (“kullanıcı e-posta ile kaydolabilmelidir”) değil, uygulama terimleriyle (“testAddUser”) formüle edildiğini fark etti. BDD, “test” kelimesini “should” ile ve “assert” kelimesini “expect” ile değiştirerek odağı kullanıcı değerine kaydırdı.

Bir İletişim Pratiği Olarak BDD

Cambridge Üniversitesi araştırmasına (2021) göre, müşteri iletişiminde BDD senaryolarını kullanan projeler, geleneksel metin belgelerindeki spesifikasyonlara kıyasla gereksinim hatalarını %35 azaltır. Çalıştırılabilir senaryolar belirsiz formülasyonlara izin vermez — her Given-When-Then ya geçer ya da kalır.

Gherkin Dili ve Sözdizimi

Gherkin, Cucumber ve SpecFlow framework'leri tarafından davranış senaryolarını tanımlamak için kullanılan alan özel bir dildir. Gherkin, senaryoları yapılandırmak için girinti ve anahtar kelimeler kullanır ve teknik geçmişi olmayan kişiler için okunabilir kalır.

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 Anahtar Kelimeleri

Gherkin birkaç temel anahtar kelime tanımlar. Feature işlevselliği tanımlar, Scenario belirli bir senaryoyu tanımlar, Given ön koşulları tanımlar, When eylemi tanımlar, Then beklenen sonucu tanımlar. Ek olarak, And ve But birden çok koşulu birleştirmek için kullanılır.

.feature Dosya Yapısı

Gherkin dosyaları .feature uzantısına sahiptir ve Android projelerinde src/test/resources/features/ dizininde saklanır. Her dosya bir Feature tanımıyla başlar ve ardından bir veya daha fazla Scenario gelir. Parametrelendirme için Examples tablolarıyla Scenario Outline kullanılır — bu, aynı senaryonun farklı verilerle çalıştırılmasına olanak tanır.

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 Formatı

Given-When-Then, BDD tarafından domain-driven design'dan benimsenmiş, senaryoları tanımlamak için yapısal bir desendir. Her senaryo üç bölümden oluşur: ön koşullar, eylem ve beklenen sonuç. Bu format doğal olarak birim testteki Arrange-Act-Assert'e karşılık gelir ancak iş dostu bir dil kullanır.

Given: Bağlam

Given bloğu, senaryo başlamadan önceki sistem durumunu tanımlar: hangi veriler mevcut, hangi bileşenler aktif, uygulama hangi modda çalışıyor. Mobil bağlamda bu, “kullanıcı giriş yaptı”, “sepet boş değil” veya “cihaz çevrimdışı modda” olabilir.

When: Eylem

When bloğu, kullanıcı veya sistem tarafından tetiklenen bir olayı tanımlar: bir düğmeye basma, push bildirimi alma, sunucu yanıtı. Mobil uygulamalarda bu genellikle bir ViewModel yönteminin çağrılmasına veya bir arayüz öğesine tıklamaya karşılık gelir.

Then: Sonuç

Then bloğu beklenen durum değişikliğini tanımlar: ekran değişimi, API çağrısı, veritabanı güncellemesi. Then içindeki kontroller ölçülebilir ve net olmalıdır — çalıştırılabilir kodda iddialara (assertions) dönüşürler.

BDD ve TDD: Yaklaşımların Karşılaştırması

BDD ve TDD sıklıkla karıştırılır, ancak bunlar farklı disiplin seviyeleridir. TDD, kod seviyesinde bir tasarım tekniğidir: “uygulama nasıl yazılır”. BDD, gereksinim seviyesinde bir spesifikasyon tekniğidir: “sistem ne yapmalı”.

Projede Tamamlayıcılık

En iyi mobil projeler, bireysel sınıf seviyesinde (domain katmanı) TDD'yi ve senaryo seviyesinde (özellik katmanı) BDD'yi kullanır. Bu çift kapsama sağlar: TDD uygulama doğruluğunu garanti eder, BDD gereksinim anlayışının doğruluğunu garanti eder. Google, dahili pratiğinde Android uygulamaları için TDD ve BDD kombinasyonunu kullanır (Android Testing dokümantasyonu 2024).

Mobil Geliştirme için BDD Araçları

BDD ekosistemi, tüm popüler mobil geliştirme platformları ve dilleri için framework'ler içerir. Araç seçimi teknoloji yığınına ve otomasyon seviyesine bağlıdır.

Android için Cucumber

Cucumber, Gherkin senaryolarıyla çalışan en popüler BDD framework'üdür. Android projeleri için io.cucumber:cucumber-android kütüphanesi kullanılır ve Espresso ile Compose Test UI test araçlarıyla entegre olur. Cucumber, Kotlin ve Java'yı destekler ve her iki dili kullanan stüdyolar için evrensel bir seçimdir.

Xamarin için SpecFlow

SpecFlow, .NET ekosistemi için bir BDD framework'üdür ve Xamarin.Forms ile .NET MAUI projelerinde kullanılır. SpecFlow, NUnit ve xUnit ile entegre olur ve step definitions'ları C# ile yazılır. Mobil projeler için SpecFlow, paylaşılan bir kod tabanında uygulamanın Android ve iOS sürümleri arasında senaryoların yeniden kullanılmasına olanak tanır.

iOS için Quick/Nimble

Swift ile iOS geliştirme için Quick ve Nimble BDD framework'leri bulunur. Quick, describe/it tarzında senaryoları tanımlamak için bir DSL sağlar ve Nimble, okunabilir sözdizimiyle eşleştiriciler sağlar. Bu framework'ler doğrudan Gherkin kullanmasa da, BDD ilkesini uygular: tüm ekip tarafından anlaşılabilir bir dilde davranışı tanımlamak.

BDD Senaryo ve Kod Örnekleri

Bir Android projesinde tam bir BDD örneğine bakalım: sipariş ödeme senaryosu. Önce bir Gherkin senaryosu yazıyoruz, ardından Kotlin'de step definitions.

BDD Çalışma Prensibi: three amigos

BDD metodolojisi, three amigos toplantısına dayanır — üç rol: geliştirici, testçi ve analist. Geliştirme başlamadan önce birlikte senaryolar yazarak gereksinimlerin ortak bir şekilde anlaşılmasını sağlarlar. Üç katılımcıdan biri bile senaryoyu anlamazsa, gereksinimin belirsiz bir şekilde formüle edildiği anlamına gelir. Bu uygulama, “Discovery: Explore Behaviour Using Examples” (Gáspár & North, 2021) kitabında açıklanmıştır ve olgun ekiplerde BDD sürecinin zorunlu bir parçasıdır.

Gherkin Sipariş Ödeme Senaryosu

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

Kotlin'de Step Definitions

Step definitions, Gherkin senaryolarını test uygulamasına bağlayan kodlardır. Her adım, bir Gherkin anahtar kelimesine karşılık gelen bir ek açıklamaya sahip bir yöntemdir.

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

Cucumber Android ile Entegrasyon

Bir Android projesinde BDD testlerini çalıştırmak için CucumberAndroidJUnitRunner kullanılır. Kaynaklardaki .feature dosyalarını tarar, düzenli ifadelerle ilgili step definitions'ları bulur ve senaryoları normal instrumented testler olarak yürütür. Sonuçlar, müşteri tarafından anlaşılabilir bir HTML raporuna biçimlendirilir.

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

Mobil Projelerde BDD Uygulamanın Zorlukları

Mobil geliştirmede BDD uygulamak bir dizi pratik zorluğu beraberinde getirir. Bu sorunları anlamak, ekiplerin hayal kırıklığını önlemesine ve sürdürülebilir bir BDD süreci oluşturmasına yardımcı olur.

.feature Dosyalarının Bakımı

Ana sorun, Gherkin senaryoları ile üretim kodu arasındaki senkronizasyon kaybıdır. Geliştiriciler, step definitions'ları güncellemeden API'leri değiştirirse, .feature dosyaları uygulamayla eşleşmez. Çözüm, CI/CD hattında BDD testlerini çalıştırmak ve birleştirme istekleri için yeşil durum talep etmektir. “BDD as a gating mechanism” uygulaması Cucumber dokümantasyonunda (2024) açıklanmıştır ve endüstri standardıdır.

BDD Test Performansı

Cucumber'daki BDD senaryoları, bir Android cihazda veya emülatörde instrumented testler olarak çalışır. Bu, JVM'deki normal birim testlerinden 10–50 kat daha yavaştır. Büyük bir Android uygulaması için tek bir kabul testi 20–30 dakika sürebilir. BDD testlerinin gece ayrı bir CI işinde çalıştırılması, birim testlerinin ise her push'ta çalıştırılması önerilir. Bu strateji, geri bildirim hızı ve senaryo kapsamı arasında denge kurar.

Ekibin Gherkin Eğitimi

BDD'ye geçiş, yalnızca geliştiricilerin değil, aynı zamanda analistlerin ve testçilerin de eğitimini gerektirir. Gherkin basit bir dildir, ancak iyi senaryolar yazmak pratik gerektirir. Yeni başlayanların tipik hataları: çok uzun senaryolar (10 adımdan fazla), Given-When-Then'in karıştırılması, iş senaryolarında teknik terimlerin kullanılması. BDD Academy'ye (2024) göre, ekiplerin BDD senaryoları yazmada olgunluğa ulaşması için ortalama 4–6 sprint gerekir.