BDD: nədir, davranış ssenariləri və framework-lər

BDD nədir?

Behavior-Driven Development — 2006-cı ildə Dan North tərəfindən təklif edilmiş TDD-nin təkamülüdür, testlərin formullaşdırılması probleminə cavab olaraq. TDD-də proqramçı test yazır, amma „məhz nəyi test etmək?“ sualı açıq qalır. BDD bu problemi həll edir, diqqəti kodun test edilməsindən sistemin davranışının təsvirinə istifadəçi baxımından yönəldir.

BDD-nin əsas yeniliyi — layihənin bütün iştirakçıları üçün ümumi dildir. Proqramçılar, testçilər, analitiklər və müştərilər ssenariləri vahid dildə müzakirə edirlər, bu da eyni anda icra edilə bilən testdir. Bu, tələblərin analitikdən proqramçıya ötürülməsi zamanı mənasını itirməsi kimi klassik „kor telefon“ problemini aradan qaldırır.

BDD-nin yaranma tarixi

Dan North BDD-ni 2006-cı ildə ThinkCode bloqunda „Introducing BDD“ məqaləsində formullaşdırmışdır. O, TDD-də test adlarının çox vaxt icra terminləri ilə („testAddUser“) ifadə edildiyini, davranış terminləri ilə („user should be able to register with email“) deyil, qeyd etmişdir. BDD „test“ sözünü „should“ və „assert“ sözünü „expect“ ilə əvəz etmiş, diqqəti istifadəçi üçün dəyərə yönəltmişdir.

BDD kommunikasiya təcrübəsi kimi

Cambridge University (2021) tədqiqatına görə, müştəri ilə ünsiyyətdə BDD ssenarilərindən istifadə edən layihələr tələblərdə səhv sayını ənənəvi mətn spesifikasiyaları ilə müqayisədə 35% azaldır. İcra edilə bilən ssenarilər qeyri-müəyyən ifadələrə yol vermir — hər Given-When-Then ya icra olunur, ya da olunmur.

Gherkin dili və sintaksisi

Gherkin — Cucumber və SpecFlow framework-ləri tərəfindən davranış ssenarilərini təsvir etmək üçün istifadə olunan domen spesifik dildir. Gherkin ssenariləri strukturlaşdırmaq üçün abzaslar və açar sözlərdən istifadə edir, eyni zamanda texniki fonu olmayan şəxs üçün oxunaqlı qalı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 açar sözləri

Gherkin bir neçə əsas açar söz müəyyən edir. Feature funksionallığı təsvir edir, Scenario — konkret ssenarini, Given — ilkin şərtləri, When — hərəkəti, Then — gözlənilən nəticəni. Əlavə olaraq And və But bir neçə şərti birləşdirmək üçün istifadə olunur.

.feature faylının strukturu

Gherkin faylları .feature genişlənməsinə malikdir və Android layihələrində src/test/resources/features/ qovluğunda saxlanılır. Hər fayl Feature təsviri ilə başlayır, ardınca bir və ya daha çox Scenario gəlir. Parametrləşdirmə üçün Examples cədvəlləri ilə Scenario Outline istifadə olunur — bu, eyni ssenarini müxtəlif məlumatlarla işə salmağa imkan verir.

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 tərəfindən domain-driven design-dan götürülmüş ssenarilərin təsviri üçün struktur nümunəsidir. Hər ssenari üç hissədən ibarətdir: ilkin şərtlər, hərəkət və gözlənilən nəticə. Bu format təbii olaraq unit-testlərdəki Arrange-Act-Assert-ə uyğun gəlir, lakin biznes üçün anlaşıqlı dildən istifadə edir.

Given: kontekst

Given bloku ssenarinin başlanğıcından əvvəl sistemin vəziyyətini təsvir edir: hansı məlumatlar mövcuddur, hansı komponentlər aktivdir, tətbiq hansı rejimdə işləyir. Mobil kontekstdə bu „istifadəçi daxil olub“, „səbət boş deyil“ və ya „cihaz oflayn rejimdədir“ ola bilər.

When: hərəkət

When bloku istifadəçi və ya sistem tərəfindən başladılan hadisəni təsvir edir: düymənin basılması, push-bildirişin alınması, server cavabı. Mobil tətbiqlərdə bu çox vaxt ViewModel metodunun çağırışına və ya UI elementinə basılmasına uyğun gəlir.

Then: nəticə

Then bloku gözlənilən vəziyyət dəyişikliyini təsvir edir: ekranın dəyişməsi, API çağırışı, verilənlər bazasının yenilənməsi. Then-də yoxlamalar ölçülə bilən və birmənalı olmalıdır — onlar icra edilə bilən koddaki assert-lərə çevrilir.

BDD və TDD: yanaşmaların müqayisəsi

BDD və TDD çox vaxt qarışdırılır, baxmayaraq ki, bunlar fərqli intizam səviyyələridir. TDD — kod səviyyəsində layihələndirmə texnikası: „icranı necə yazmaq“. BDD — tələb səviyyəsində spesifikasiya texnikası: „sistem nə etməlidir“.

Layihədə qarşılıqlı tamamlama

Ən yaxşı mobil layihələr ayrı-ayrı siniflər səviyyəsində (domain təbəqəsi) TDD və ssenari səviyyəsində (feature təbəqəsi) BDD istifadə edir. Bu ikiqat əhatə verir: TDD icranın düzgünlüyünü, BDD isə tələblərin düzgün başa düşüldüyünü təmin edir. Google öz daxili təcrübəsində Android proqramları üçün TDD və BDD kombinasiyasından istifadə edir, Android Testing (2024) sənədləşməsində göstərildiyi kimi.

Mobil inkişaf üçün BDD alətləri

BDD ekosistemi mobil inkişafın bütün populyar platformaları və dilləri üçün framework-ləri əhatə edir. Alətin seçimi texnoloji stekdən və avtomatlaşdırma səviyyəsindən asılıdır.

Android üçün Cucumber

Cucumber — Gherkin ssenariləri ilə işləyən ən populyar BDD framework-üdür. Android layihələri üçün io.cucumber:cucumber-android kitabxanası istifadə olunur, bu da Espresso və Compose Test UI-test alətləri ilə inteqrasiya olunur. Cucumber Kotlin və Java-nı dəstəkləyir, bu da onu hər iki dildən istifadə edən studiyalar üçün universal seçim edir.

Xamarin üçün SpecFlow

SpecFlow — .NET ekosistemi üçün BDD framework-ü, Xamarin.Forms və .NET MAUI layihələrində istifadə olunur. SpecFlow NUnit və xUnit ilə inteqrasiya olunur, onun addımları (step definitions) C# dilində yazılır. Mobil layihələr üçün SpecFlow ssenariləri ümumi kod bazasında Android və iOS versiyaları arasında təkrar istifadə etməyə imkan verir.

iOS üçün Quick/Nimble

Swift-də iOS inkişafı üçün Quick və Nimble BDD framework-ləri mövcuddur. Quick describe/it stilində ssenariləri təsvir etmək üçün DSL təqdim edir, Nimble isə oxunaqlı sintaksisli matçerlər təqdim edir. Bu framework-lər Gherkin-dən birbaşa istifadə etməsələr də, BDD prinsipini həyata keçirirlər: davranışın bütün komanda üçün anlaşıqlı dildə təsviri.

BDD ssenariləri və kod nümunələri

Android layihəsində BDD-nin tam nümunəsini nəzərdən keçirək: sifariş vermə ssenarisi. Əvvəlcə Gherkin ssenarisi yazırıq, sonra — Kotlin dilində step definitions.

BDD iş prinsipi: three amigos

BDD metodologiyası three amigos — üç rolun: proqramçı, testçi və analitikin görüşünə əsaslanır. Onlar inkişafa başlamazdan əvvəl birlikdə ssenarilər yazır, tələblərin ümumi başa düşülməsini təsbit edirlər. Əgər ssenari üç iştirakçıdan heç biri üçün uyğun deyilsə — demək, tələb qeyri-müəyyən formullaşdırılıb. Bu təcrübə “Discovery: Explore Behaviour Using Examples” (Gáspár & North, 2021) kitabında təsvir edilmişdir və yetkin komandalarda BDD prosesinin məcburi hissəsidir.

Sifariş vermə Gherkin ssenarisi

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-də step definitions

Step definitions — Gherkin ssenarisini test icrası ilə birləşdirən kod. Hər addım Gherkin açar sözünə uyğun annotasiyalı metoddur.

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 ilə inteqrasiya

Android layihəsində BDD testlərini işə salmaq üçün CucumberAndroidJUnitRunner istifadə olunur. O, resurslardakı .feature fayllarını skan edir, müvafiq step definitions-ləri müntəzəm ifadələrlə tapır və ssenariləri adi instrumental testlər kimi icra edir. Nəticələr müştəri üçün anlaşıqlı HTML hesabatında formatlaşdırılır.

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

BDD-nin mobil layihələrdə tətbiqində çətinliklər

BDD-nin mobil inkişafa tətbiqi bir sıra praktiki çətinliklərlə bağlıdır. Bu problemlərin dərk edilməsi komandalara məyusluqdan qaçmağa və davamlı BDD prosesi qurmağa kömək edir.

.feature fayllarının saxlanması

Əsas problem — Gherkin ssenariləri ilə istehsal kodu arasında desinxronizasiyadır. Əgər proqramçılar API-ni dəyişir, step definitions-i yeniləmirlərsə, .feature faylları icraya uyğun gəlmir. Həll yolu — BDD testlərini CI/CD pipeline-da işə salmaq və merge request üçün yaşıl status tələb etməkdir. „BDD as a gating mechanism“ təcrübəsi Cucumber (2024) sənədləşməsində təsvir edilmişdir və sənayedə standartdır.

BDD testlərinin performansı

Cucumber-də BDD ssenariləri Android cihazında və ya emulyatorda instrumental testlər vasitəsilə icra olunur. Bu, JVM-də adi unit-testlərdən 10–50 dəfə yavaşdır. Böyük Android tətbiqi üçün bir qəbul testi 20–30 dəqiqə çəkə bilər. BDD testlərini ayrıca CI işinə ayırmaq və onları gecə işə salmaq, unit-testləri isə hər push-da işə salmaq tövsiyə olunur. Bu strategiya rəy sürəti və ssenari əhatəsi arasında tarazlıq yaradır.

Komandanın Gherkin öyrənməsi

BDD-yə keçid yalnız proqramçıların deyil, həm də analitiklər və testçilərin təlimini tələb edir. Gherkin sadə dildir, lakin yaxşı ssenarilər yazmaq təcrübə tələb edir. Başlayanların tipik səhvləri: çox uzun ssenarilər (10 addımdan çox), Given-When-Then-in qarışdırılması, biznes ssenarilərində texniki terminlərin istifadəsi. BDD Academy (2024) məlumatına görə, komandalara BDD ssenarilərinin yazılmasında yetkinliyə çatmaq üçün orta hesabla 4–6 sprint lazımdır.