BDD: nima, xatti-harakat stsenariylari va freymvorklar

BDD nima?

Behavior-Driven Development — 2006-yilda Dan North tomonidan testlarni shakllantirish muammosiga javob sifatida taklif qilingan TDD evolyutsiyasidir. TDDda dasturchi test yozadi, ammo „aynan nimani test qilish?“ degan savol ochiq qoladi. BDD bu muammoni hal qiladi, diqqatni kodni test qilishdan tizimning xatti-harakatini tasvirlashga foydalanuvchi nuqtayi nazaridan o'zgartiradi.

BDDning asosiy yangiligi — loyihaning barcha ishtirokchilari uchun umumiy til. Dasturchilar, testerlar, analitiklar va mijozlar stsenariylarni yagona tilda muhokama qiladilar, bu bir vaqtning o'zida bajariladigan testdir. Bu talablarning analitikdan dasturchiga o'tishda ma'nosini yo'qotishi kabi klassik „buzuq telefon“ muammosini bartaraf qiladi.

BDDning paydo bo'lish tarixi

Dan North BDDni 2006-yilda ThinkCode blogidagi „Introducing BDD“ maqolasida shakllantirgan. U TDDda test nomlari ko'pincha amalga oshirish terminlari bilan („testAddUser“) ifodalanishini, xatti-harakat terminlari bilan („user should be able to register with email“) emasligini ta'kidlagan. BDD „test“ so'zini „should“ va „assert“ so'zini „expect“ bilan almashtirib, diqqatni foydalanuvchi uchun qiymatga qaratgan.

BDD aloqa amaliyoti sifatida

Cambridge University (2021) tadqiqotiga ko'ra, mijoz bilan muloqotda BDD stsenariylaridan foydalanadigan loyihalar talablardagi xatolar sonini an'anaviy matnli spetsifikatsiyalarga nisbatan 35% ga kamaytiradi. Bajariladigan stsenariylar noaniq iboralarga yo'l qo'ymaydi — har bir Given-When-Then yoki bajariladi yoki bajarilmaydi.

Gherkin tili va sintaksisi

Gherkin — Cucumber va SpecFlow freymvorklari tomonidan xatti-harakat stsenariylarini tasvirlash uchun ishlatiladigan domenga oid tildir. Gherkin stsenariylarni tuzish uchun abzaslar va kalit so'zlardan foydalanadi, shu bilan birga texnik ma'lumotga ega bo'lmagan odam uchun o'qilishi mumkin bo'lib qoladi.

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 kalit so'zlari

Gherkin bir nechta asosiy kalit so'zlarni belgilaydi. Feature funksionallikni, Scenario — aniq stsenariyni, Given — old shartlarni, When — harakatni, Then — kutilgan natijani tasvirlaydi. Qo'shimcha ravishda And va But bir nechta shartlarni birlashtirish uchun ishlatiladi.

.feature faylining tuzilishi

Gherkin fayllari .feature kengaytmasiga ega va Android loyihalarida src/test/resources/features/ katalogida saqlanadi. Har bir fayl Feature tavsifi bilan boshlanadi, undan keyin bir yoki bir nechta Scenario keladi. Parametrlash uchun Examples jadvallari bilan Scenario Outline ishlatiladi — bu bir xil stsenariyni turli ma'lumotlar bilan ishga tushirish imkonini beradi.

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 formati

Given-When-Then — BDD tomonidan domain-driven design-dan olingan stsenariylarni tasvirlash uchun strukturaviy naqshdir. Har bir stsenariy uch qismdan iborat: old shartlar, harakat va kutilgan natija. Bu format tabiiy ravishda unit-testlardagi Arrange-Act-Assert ga mos keladi, lekin biznes uchun tushunarli tildan foydalanadi.

Given: kontekst

Given bloki stsenariy boshlanishidan oldin tizimning holatini tasvirlaydi: qanday ma'lumotlar mavjud, qaysi komponentlar faol, dastur qaysi rejimda ishlaydi. Mobil kontekstda bu „foydalanuvchi tizimga kirdi“, „savat bo'sh emas“ yoki „qurilma oflayn rejimda“ bo'lishi mumkin.

When: harakat

When bloki foydalanuvchi yoki tizim tomonidan boshlangan hodisani tasvirlaydi: tugmani bosish, push-bildirishnoma olish, server javobi. Mobil ilovalarda bu ko'pincha ViewModel metodini chaqirish yoki UI elementini bosishga mos keladi.

Then: natija

Then bloki kutilgan holat o'zgarishini tasvirlaydi: ekran o'zgarishi, API chaqiruvi, ma'lumotlar bazasini yangilash. Then tekshiruvlari o'lchanadigan va bir ma'noli bo'lishi kerak — ular bajariladigan koddagi assertlarga aylanadi.

BDD va TDD: yondashuvlarni solishtirish

BDD va TDD ko'pincha aralashtiriladi, garchi ular turli intizom darajalari bo'lsa ham. TDD — kod darajasida loyihalash texnikasi: „amalga oshirishni qanday yozish“. BDD — talab darajasida spetsifikatsiya texnikasi: „tizim nima qilishi kerak“.

Loyihada o'zaro to'ldirish

Eng yaxshi mobil loyihalar alohida sinflar darajasida (domain qatlami) TDD va stsenariy darajasida (feature qatlami) BDD dan foydalanadi. Bu ikki tomonlama qamrovni beradi: TDD amalga oshirishning to'g'riligini, BDD esa talablarni to'g'ri tushunishni kafolatlaydi. Google o'z ichki amaliyotida Android ilovalari uchun TDD va BDD kombinatsiyasidan foydalanadi, Android Testing (2024) hujjatlarida ko'rsatilganidek.

Mobil ishlab chiqish uchun BDD vositalari

BDD ekotizimi mobil ishlab chiqishning barcha mashhur platformalari va tillari uchun freymvorklarni o'z ichiga oladi. Vositani tanlash texnologik stek va avtomatlashtirish darajasiga bog'liq.

Android uchun Cucumber

Cucumber — Gherkin stsenariylari bilan ishlaydigan eng mashhur BDD freymvorkidir. Android loyihalari uchun io.cucumber:cucumber-android kutubxonasi ishlatiladi, u Espresso va Compose Test UI-test vositalari bilan integratsiyalanadi. Cucumber Kotlin va Java-ni qo'llab-quvvatlaydi, bu uni ikkala tildan foydalanadigan studiyalar uchun universal tanlov qiladi.

Xamarin uchun SpecFlow

SpecFlow — .NET ekotizimi uchun BDD freymvorki, Xamarin.Forms va .NET MAUI loyihalarida ishlatiladi. SpecFlow NUnit va xUnit bilan integratsiyalanadi, uning qadamlari (step definitions) C# tilida yoziladi. Mobil loyihalar uchun SpecFlow stsenariylarni umumiy kod bazasida Android va iOS versiyalari o'rtasida qayta ishlatish imkonini beradi.

iOS uchun Quick/Nimble

Swiftda iOS ishlab chiqish uchun Quick va Nimble BDD freymvorklari mavjud. Quick describe/it uslubida stsenariylarni tasvirlash uchun DSL taqdim etadi, Nimble esa o'qilishi mumkin bo'lgan sintaksisli matcherlarni taqdim etadi. Bu freymvorklar Gherkindan to'g'ridan-to'g'ri foydalanmasalar ham, BDD prinsipini amalga oshiradilar: butun jamoa uchun tushunarli tilda xatti-harakatni tasvirlash.

BDD stsenariylari va kod namunalari

Android loyihasida BDDning to'liq namunasini ko'rib chiqaylik: buyurtma berish stsenariysi. Avval Gherkin stsenariysini yozamiz, keyin — Kotlin tilida step definitions.

BDD ishlash prinsipi: three amigos

BDD metodologiyasi three amigos — uchta rol: dasturchi, tester va analitik uchrashuviga asoslanadi. Ular ishlab chiqish boshlanishidan oldin birgalikda stsenariylarni yozadilar, talablarning umumiy tushunilishini qayd etadilar. Agar stsenariy uch ishtirokchining hech biriga mos kelmasa — demak, talab noaniq shakllantirilgan. Bu amaliyot „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) kitobida tasvirlangan va yetuk jamoalarda BDD jarayonining majburiy qismidir.

Buyurtma berish Gherkin stsenariysi

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 tilida step definitions

Step definitions — Gherkin stsenariysini test amalga oshirish bilan bog'laydigan kod. Har bir qadam Gherkin kalit so'ziga mos keladigan annotatsiyalangan metoddir.

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 bilan integratsiya

Android loyihasida BDD testlarini ishga tushirish uchun CucumberAndroidJUnitRunner ishlatiladi. U resurslardagi .feature fayllarini skanerlaydi, tegishli step definitionslarni muntazam ifodalar bilan topadi va stsenariylarni oddiy instrumental testlar sifatida bajaradi. Natijalar mijoz uchun tushunarli HTML hisobotida formatlanadi.

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

BDDni mobil loyihalarda joriy etish qiyinchiliklari

BDDni mobil ishlab chiqishga joriy etish bir qator amaliy qiyinchiliklar bilan bog'liq. Bu muammolarni anglash jamoalarga umidsizlikdan qochish va barqaror BDD jarayonini qurishga yordam beradi.

.feature fayllarini saqlash

Asosiy muammo — Gherkin stsenariylari va ishlab chiqarish kodi o'rtasidagi desinxronizatsiya. Agar dasturchilar API-ni o'zgartirib, step definitionslarni yangilamasalar, .feature fayllari amalga oshirishga mos kelmaydi. Yechim — BDD testlarini CI/CD pipeline-da ishga tushirish va merge request uchun yashil status talab qilish. „BDD as a gating mechanism“ amaliyoti Cucumber (2024) hujjatlarida tasvirlangan va sanoatda standartdir.

BDD testlarining unumdorligi

Cucumberdagi BDD stsenariylari Android qurilmasida yoki emulyatorda instrumental testlar orqali bajariladi. Bu JVMdagi oddiy unit-testlardan 10–50 marta sekinroq. Bitta qabul testi katta Android ilovasi uchun 20–30 daqiqa davom etishi mumkin. BDD testlarini alohida CI ishiga ajratish va ularni tunda ishga tushirish, unit-testlarni esa har bir pushda ishga tushirish tavsiya etiladi. Bunday strategiya fikr-mulohaza tezligi va stsenariy qamrovi o'rtasida muvozanat yaratadi.

Jamoani Gherkin o'rgatish

BDDga o'tish nafaqat dasturchilarni, balki analitiklar va testerlarni ham o'qitishni talab qiladi. Gherkin oddiy til, ammo yaxshi stsenariylar yozish amaliyot talab qiladi. Boshlovchilarning odatiy xatolari: juda uzun stsenariylar (10 qadamdan ortiq), Given-When-Then ni aralashtirish, biznes stsenariylarida texnik atamalarni ishlatish. BDD Academy (2024) ma'lumotiga ko'ra, jamoalarga BDD stsenariylarini yozishda yetuklikka erishish uchun o'rtacha 4–6 sprint kerak bo'ladi.