Given-When-Then: bu nima, stsenariy tuzilishi va misollar

Given-When-Then nima?

Given-When-Then — birinchi marta 2006-yilda Dan North tomonidan Behavior-Driven Development metodologiyasining bir qismi sifatida shakllantirilgan xatti-harakatni tavsiflash andozasidir. Andoza ko'pincha old shartlar, harakatlar va tekshirishlarning ixtiyoriy tartibda aralashmasini o'z ichiga olgan tuzilmagan test stsenariy tavsiflari muammosini hal qiladi.

Andozaning asosiy g'oyasi uch blok o'rtasida mas'uliyatlarni ajratishdir. Har bir blok stsenariyning bir jihati uchun javobgardir: oldingi holat, voqea va keyingi tekshirish. Bu stsenariyni o'qiladigan, tekshiriladigan va avtomatlashtiriladigan qiladi. Cucumber freymvorki ishlab chiqaruvchilarining tadqiqotiga (2024) ko'ra, Given-When-Then andozasiga qat'iy rioya qiladigan stsenariylar jamoa yangi a'zosi tomonidan tushunish uchun 42% kamroq vaqt talab qiladi.

Andozaning kelib chiqishi

Dan North uch qismli struktura g'oyasini TDD-dagi formulation of tests va Test-by-Example metodologiyasidan (Brian Marick tomonidan yaratilgan) olgan. Marick talablarni bir vaqtning o'zida test sifatida xizmat qiladigan misollar (examples) orqali tavsiflashni taklif qilgan. Given-When-Then ushbu g'oyani rasmiylashtirib, tuzilmagan misollarni takrorlanadigan andozaga aylantirdi.

Qo'llash sohasi

Given-When-Then andozasi nafaqat Gherkin-dagi BDD stsenariylarida, balki JUnit, XCTest va boshqa freymvorklardagi oddiy birlik testlarida ham qo'llaniladi. Testni uch blokga ajratadigan koddagi sharhlar test bazasining o'qilishini yaxshilash uchun keng tarqalgan amaliyotdir. Google ushbu yondashuvni „Software Engineering at Google” (2020) kitobida tavsiya qiladi.

Uch blokning tuzilishi

Har bir Given-When-Then bloki qat'iy belgilangan semantika va to'ldirish qoidalariga ega. Ushbu qoidalarni buzish avtomatlashtirish yoki tushunish qiyin bo'lgan stsenariylarga olib keladi.

Given: old shartlar

Given bloki sinovdan o'tkaziladigan harakatni bajarishdan oldin tizimning holatini tavsiflaydi. Bunga kiradi: mavjud ob'ektlar (foydalanuvchi, buyurtma, sozlamalar), faol holatlar (avtorizatsiyadan o'tgan, tarmoqqa ulangan), shuningdek ma'lumotlarning boshlang'ich qiymatlari. Har bir Given tekshiriladigan bo'lishi kerak — agar tizim holati Given-ga mos kelmasa, stsenariy o'tkazib yuborilishi yoki test muhiti oldindan tayyorlanishi kerak.

When: harakat

When bloki sinovdan o'tkaziladigan xatti-harakatni boshlaydigan yagona voqeani tavsiflaydi. Bu metodni chaqirish, tugmani bosish, bildirishnoma yoki serverdan javob olish bo'lishi mumkin. Asosiy qoida — har bir stsenariy uchun bitta When. Agar harakatlar ketma-ketligini tekshirish kerak bo'lsa, When zanjiri emas, balki alohida stsenariylar yaratiladi.

// Given: test ma'lumotlarini yaratamiz
val user = User(email = "test@example.com", balance = 500.0)
val product = Product(price = 150.0)

// When: harakatni bajaramiz
val result = PurchaseUseCase().buy(user, product)

// Then: natijani tekshiramiz
assertEquals(PurchaseResult.Success, result)
assertEquals(350.0, user.balance)

Then: kutilgan natija

Then bloki tizim kutilgan holatga o'tganligini tekshiradi. Bunga kiradi: qaytarilgan qiymatlar, ob'ektlar holatining o'zgarishlari, tashqi xizmatlarning chaqiruvlari (mock tekshiruvi orqali), shuningdek UI o'zgarishlari. Har bir Then bloki bir nechta tekshirishni o'z ichiga olishi mumkin, ammo ularning barchasi bitta harakatga tegishli.

Given-When-Then va Arrange-Act-Assert

Given-When-Then va Arrange-Act-Assert (AAA) — bir xil uch qismli andozaning ikki variantidir, ammo turli maqsadli auditoriya bilan. Ularning farqlarini tushunish muayyan vazifa uchun to'g'ri formatni tanlashga yordam beradi.

Qachon Given-When-Then ishlatiladi

Given-When-Then andozasi mijoz yoki analitik bilan muhokama qilinadigan stsenariylar uchun optimaldir: funksiyalarni qabul qilish mezonlari, foydalanish stsenariylari, regressiya tekshiruvlari. Gherkin sintaksisi dasturlashni bilmagan holda bunday stsenariylarni yozishga imkon beradi.

Qachon Arrange-Act-Assert ishlatiladi

Arrange-Act-Assert — muayyan metod yoki sinfni tekshiradigan birlik testlari uchun tabiiy tanlovdir. AAA formati qo'shimcha freymvorklarni talab qilmaydi va har qanday dasturlash tilida ishlaydi. iOS ishlanmasi uchun Apple XCTest (2024) hujjatlarida AAA-ni tavsiya qiladi.

Kotlin-da stsenariy misollari

Android ilovasi uchun Kotlin tilida Given-When-Then-ning amaliy misollarini ko'rib chiqamiz. Birinchi misol — MockK yordamida xarid savatini testlash. Ikkinchi — push bildirishnomalari mantiqini testlash.

Misol 1: xarid savati

class CartTest {
    fun `apply discount when total exceeds threshold`() {
        // Given
        val cart = Cart()
        cart.addItem(Item("Laptop", price = 1000.0))
        cart.addItem(Item("Mouse", price = 50.0))
        val discount = DiscountCalculator(0.1)

        // When
        val total = discount.applyIfEligible(cart)

        // Then
        assertEquals(945.0, total)
        assertTrue("Discount was not applied", total < 1050.0)
    }
}

Misol 2: korutinlar bilan push bildirishnomalari

Ikkinchi misol asinxron kod bilan Given-When-Then-ni namoyish etadi. Bu yerda Given Firebase Cloud Messaging holatini, When — push bildirishnomasini olishni, Then — qayta ishlashni tekshirishni belgilaydi.

class PushNotificationTest {
    fun `handle push notification when app in background`() = runTest {
        // Given
        val prefs = mockk<SharedPreferences>()
        every { prefs.getString("token", null) } returns "fcm-token-abc"
        val handler = PushHandler(prefs)

        // When
        val data = RemoteMessage().apply {
            putData("type", "order_update")
            putData("order_id", "123")
        }
        val result = handler.handleNotification(data)

        // Then
        assertEquals(NotificationAction.OpenOrder("123"), result)
    }
}

Misol 3: avtorizatsiya uchun Gherkin stsenariysi

Uchinchi misol — qabul testlari kontekstida Given-When-Then-ni ko'rsatadigan Gherkin-dagi BDD stsenariysi:

Feature: User Authorization
  Scenario: User cannot login with expired token
    Given the user has an expired refresh token
    When they try to access the protected profile screen
    Then they should see the login screen
    And the app should clear all cached data

Stsenariy yozishning eng yaxshi amaliyotlari

Given-When-Then-ni samarali qo'llash bir nechta sinovdan o'tgan amaliyotlarga rioya qilishni talab qiladi. Ular stsenariylarning o'qilishi, saqlanishi va avtomatlashtirilishini ta'minlaydi.

Har bir stsenariy uchun bitta When

Qattiq qoida: bitta stsenariy — bitta harakat. Agar bir nechta When ketma-ketligini tekshirish kerak bo'lsa, bir nechta stsenariy yarating, bunda oldingisining natijasi keyingisi uchun old shart bo'ladi. Bu stsenariyni atomar va tushunarli qiladi.

Given-da aniq ma'lumotlardan saqlaning

Given mohiyatni tavsiflashi kerak, aniq raqamlarni emas. „Given foydalanuvchi Ivanov 500 rubl balans bilan” o'rniga — „Given yetarli balansga ega foydalanuvchi”. Aniq ma'lumotlar Examples jadvali bilan Scenario Outline-ga chiqariladi. Bu stsenariyni universal va qayta foydalanish mumkin qiladi.

• Then-ni o'lchanadigan tasdiqlar sifatida yozing — „foydalanuvchi kirish ekranini ko'rishi kerak”, „foydalanuvchi yo'naltirilishi kerak” emas
• Bir xil turdagi qadamlar uchun And dan foydalaning — agar bir nechta Given kerak bo'lsa, ularni And orqali birlashtiring, ikkinchi Given yaratmang
• Abstraksiya darajalarini aralashtirmang — Given-When-Then bir darajada bo'lishi kerak: biznes yoki texnik, ammo aralash emas
• Stsenariy sababini hujjatlashtiring — .feature faylining boshida biznes qoidasining tavsifi bilan sharh kontekstga yordam beradi

Given-When-Then CI/CD pipeline-da

Given-When-Then stsenariylarini uzluksiz integratsiya pipeline-iga integratsiyalash ularni hujjatlardan regressiyalardan himoyaga aylantiradi. Mobil loyihada har bir merge request avtomatik ravishda BDD stsenariylarini ishga tushiradi va hech bo'lmaganda bitta stsenariy muvaffaqiyatsiz bo'lsa, birlashtirishni bloklaydi.

Stsenariylarni avtomatik ishga tushirish

Android uchun Cucumber-dagi BDD stsenariylari Gradle topshirig'i ./gradlew cucumber orqali ishga tushiriladi. iOS (Quick/Nimble) uchun — xcodebuild test orqali. CI tizimlarida (GitHub Actions, GitLab CI, Bitrise) BDD testlari emulyatorlarda yoki real qurilmalarda bajariladi. Hisobot menejerlar uchun tushunarli HTML formatida tayyorlanadi: yashil stsenariylar — o'tdi, qizil — qadam ko'rsatilgan holda muvaffaqiyatsiz.

Repozitoriyada jonli hujjatlashtirish

.feature fayllari kod bilan yonma-yon repozitoriyada saqlanadi va code review-dan o'tadi. Analitik ishlanmani boshlashdan oldin yangi stsenariylar bilan merge request yaratadi (BDD-first). Ishlab chiquvchi ushbu stsenariylarning yashil bo'lishi uchun step definitions va amalga oshirishni yozadi. Barcha stsenariylar o'tganda — funksionallik tayyor. Gojko Adzicning „Specification by Example” (2011) kitobida tasvirlangan bunday yondashuv talablarni bajariladigan artefaktga aylantiradi.