Behavior-Driven Development, qisqacha BDD — dastur talablarini foydalanuvchi yoki biznes nuqtayi nazaridan kuzatiladigan xatti-harakatlar orqali ifodalashga asoslangan ishlab chiqish yondashuvidir. Unda mahsulot egasi, dasturchi va testchi bir xil misollar ustida kelishadi; bu misollar keyinchalik avtomatlashtiriladigan qabul testlariga aylanishi mumkin.
Hamkorlikka asoslangan jarayon
BDD faqat test yozish sintaksisi emas. Jarayon odatda talabni muhokama qilishdan boshlanadi. Jamoa mavhum jumlani aniq vaziyatlar bilan tekshiradi: boshlang‘ich holat qanday, qaysi hodisa yuz beradi va tashqaridan qanday natija ko‘rinadi. Noaniq atamalar, yashirin biznes qoidalari va istisnolar shu suhbatda aniqlanadi.
Misollar talabning o‘rnini to‘liq bosmaydi, ammo uning chegarasini ko‘rsatadi. Masalan, chegirma hisoblash funksiyasi uchun oddiy xarid, minimal summa chegarasi va muddati o‘tgan aksiya alohida holat sifatida muhokama qilinadi. Har bir misol tekshiriladigan bo‘lishi kerak; “tizim qulay ishlaydi” kabi subyektiv natija avtomatik baholash uchun yetarli emas.
Given–When–Then shakli
BDD senariylari ko‘pincha Given, When va Then kalit so‘zlari bilan yoziladi:
- Given tekshiruvdan oldingi kontekstni belgilaydi;
- When foydalanuvchi amali yoki hodisani ifodalaydi;
- Then kuzatilishi kerak bo‘lgan natijani ko‘rsatadi.
And va But bir xil turdagi bir necha qadamni o‘qishga qulay bog‘laydi. Ushbu shakl sabab va natijani ajratishga yordam beradi, lekin barcha texnik tafsilotni matnga joylash talab qilinmaydi. Senariy ichki metodlar ketma-ketligini emas, tizimning tashqi xatti-harakatini tasvirlasa, implementatsiya o‘zgarganda ham barqarorroq qoladi.
Executable specification
Gherkin kabi tillarda yozilgan feature faylni BDD vositasi o‘qiydi. Har qadam step definition deb ataladigan dasturiy bog‘lovchiga moslanadi. Bog‘lovchi brauzer, API yoki xizmat qatlamiga murojaat qilib, natijani tekshiradi. Shu tariqa tabiiy tilga yaqin spetsifikatsiya bajariladigan testga aylanadi.
Bajariladigan spetsifikatsiya hujjat va dastur orasidagi tafovutni kamaytiradi: talab o‘zgarsa senariy ham, unga mos kod ham yangilanadi. Biroq feature faylni barcha mayda texnik holatlar bilan to‘ldirish o‘qishni qiyinlashtiradi. Past darajadagi kombinatsiyalar unit yoki integration testlarda tekshirilishi, BDD senariysi esa biznes qiymati ko‘rinadigan misolni saqlashi mumkin.
Abstraksiya darajasi
Yaxshi senariy “tugmani bosadi, CSS selektorni topadi” demaydi; “mijoz buyurtmani tasdiqlaydi” kabi domen tilidan foydalanadi. UI tafsiloti step definition ichida qoladi. Bu yondashuv interfeys o‘zgarganda ko‘plab feature fayllarni qayta yozish zaruratini kamaytiradi.
Shu bilan birga, haddan tashqari umumiy qadam ham noaniqlik keltiradi. “Tizim to‘g‘ri ishlaydi” natijasi o‘rniga buyurtma holati, hisoblangan summa yoki qaytarilgan xato kodi kabi kuzatiladigan dalil beriladi. Jamoa ubiquitous language, ya’ni domen bo‘yicha kelishilgan atamalardan izchil foydalanadi.
Testlar piramidasidagi o‘rni
BDD senariysi brauzer orqali end-to-end test sifatida bajarilishi shart emas. Xatti-harakatni API yoki domen qatlamida tezroq va ishonchli tekshirish mumkin. Bajarish darajasi talabni qaysi chegarada tekshirish zarurligiga qarab tanlanadi. Juda ko‘p sekin UI senariylari qayta aloqa vaqtini uzaytiradi va muhitdagi kichik o‘zgarishlarga sezgir bo‘ladi.
BDD TDDni avtomatik almashtirmaydi. TDD dastur dizaynini kichik test–kod–refaktor sikli orqali boshqarishi mumkin, BDD esa talab va misollar bo‘yicha umumiy tushunishni kuchaytiradi. Ular bir loyihada birga ishlatilishi mumkin.
Natijalar muntazam qayta ko‘riladi.
Bog‘liq tushunchalar
Scenario, Step definition, Gherkin, Acceptance test, TDD, Ubiquitous language