BDD — dasturiy behaviorni biznes, test va development jamoalari tushunadigan misollar orqali ifodalashga asoslangan development yondashuvi. To‘liq nomi Behavior-Driven Development. BDD “tizim ichida qaysi method ishlaydi”dan ko‘ra “foydalanuvchi yoki biznes nuqtayi nazaridan qanday behavior kuzatiladi” degan savolga urg‘u beradi.
BDD ko‘pincha Given–When–Then formatidagi ssenariylar bilan bog‘lanadi.
Given–When–Then
Ssenariy uch qismga bo‘linadi:
- Given — boshlang‘ich sharoit;
- When — action yoki hodisa;
- Then — kutilgan observable natija.
Masalan:
Given foydalanuvchining tokeni eskirgan
When u himoyalangan sahifani ochadi
Then tizim login sahifasiga yo‘naltiradi
Behavior
BDD testning ichki implementationga emas, tashqaridan ko‘rinadigan xatti-harakatga bog‘lanishini xohlaydi.
Masalan, AuthService.validate() ikki marta chaqirildi degan tekshiruvdan ko‘ra, noto‘g‘ri token bilan access rad etildi degan behavior barqarorroq.
Refactor ssenariyni buzmasligi kerak.
Ubiquitous language
Jamoa biznesda ishlatiladigan bir xil terminlardan foydalanadi.
Masalan:
- buyurtma;
- bron;
- aktiv obuna;
- tasdiqlangan foydalanuvchi;
- yetkazib berish oynasi.
Kod, ssenariy va muhokamada bir xil ma’no saqlanadi.
Noaniq synonym requirement xatosini yaratishi mumkin.
Three Amigos
BDD amaliyotida ko‘pincha biznes vakili, developer va tester feature oldidan birga misollarni muhokama qiladi.
Maqsad:
- noaniqlikni topish;
- boundary case;
- acceptance criteria;
- terminology;
- risk.
Bu meetingning nomidan ko‘ra hamkorlik tamoyili muhim.
Feature
Behavior ssenariylari feature yoki capability ostida guruhlanadi.
Feature userga beriladigan qiymatni tavsiflaydi.
Masalan:
Feature: parolni tiklash
Ichida turli success va failure ssenariylar bo‘ladi.
Scenario
Scenario bitta aniq misol.
U ortiqcha ko‘p actionni qamramasligi kerak.
“Foydalanuvchi butun saytni ishlatadi” ssenariysi diagnostika va maintenance uchun yomon.
Har ssenariy bitta business qoida yoki flow’ni ko‘rsatadi.
Scenario Outline
Bir behavior turli data bilan takrorlansa table ishlatiladi.
Masalan:
role | expected access
admin | allowed
editor | allowed
viewer | denied
Bu duplicationni kamaytiradi.
Jadval juda katta bo‘lsa requirement o‘rniga test datasetga aylanib ketadi.
Gherkin
BDD tool’larida keng ishlatiladigan matn sintaksisi.
Keywordlar:
Gherkin matni executable bo‘lishi mumkin, ammo o‘zi test logicini bajarmaydi.
Step definition
Gherkin qadami code bilan bog‘lanadi.
Masalan:
Given aktiv user mavjud
step definition database yoki API orqali user yaratadi.
Step juda umumiy regex bilan ko‘p ma’noga mos tushmasligi kerak.
Living documentation
Ssenariylar application bilan birga bajarilib tursa ular doimiy hujjat vazifasini bajaradi.
Yiqilgan yoki eskirgan ssenariy hujjatning haqiqiy holatga mos emasligini ko‘rsatadi.
Faqat yozilib, CI’da ishlamaydigan feature fayllari tez eskiradi.
Declarative va imperative ssenariy
Imperative:
inputga email yoz
buttonni bos
2 soniya kut
Declarative:
When foydalanuvchi to‘g‘ri ma’lumot bilan ro‘yxatdan o‘tadi
Declarative ssenariy business ma’nosini saqlaydi.
Past darajadagi UI step page object yoki helperda yashiriladi.
UIga bog‘lanish
Barcha BDD ssenariylarni browser orqali bajarish shart emas.
Domain behavior API yoki service darajasida tezroq test qilinishi mumkin.
Faqat user interaction muhim bo‘lgan ssenariy E2E bo‘ladi.
Bu suite’ni tez va barqaror saqlaydi.
BDD va TDD
TDD kichik code design sikliga urg‘u beradi.
BDD behavior va shared understandingga urg‘u beradi.
Ular birga ishlashi mumkin:
- BDD acceptance ssenariy;
- TDD orqali ichki implementation;
- yakunda ssenariy yashil.
BDD va ATDD
ATDD acceptance testlarni implementationdan oldin biznes, developer va tester bilan belgilaydi.
BDD unga juda yaqin.
BDD terminology, example va behavior conversationiga ko‘proq urg‘u beradi.
Amaliy jamoalarda chegaralar kesishishi mumkin.
Automation
Ssenariyni avtomatlashtirish qimmat bo‘lsa ham uning muhokamasi foydali.
Har requirementni Gherkin va browser automationga aylantirish shart emas.
Faqat uzoq muddatli, muhim va qayta tekshiriladigan behaviorlar avtomatlashtiriladi.
Anti-pattern
Yomon BDD ssenariylar:
- juda texnik;
- database column nomlariga bog‘liq;
- uzun;
- umumiy step bilan noaniq;
- copy-paste;
- faqat tester tushunadi;
- business qiymati yo‘q.
Feature fayl test code’ning boshqa sintaksisdagi nusxasi bo‘lmasligi kerak.
Failure diagnostikasi
Ssenariy yiqilganda qaysi Given, When yoki Then qadamda muammo bo‘lgani ko‘rinadi.
Screenshot, API log va trace qo‘shiladi.
Bir step ichida juda ko‘p yashirin action bo‘lsa xato sababi noaniq bo‘ladi.
Rule
Feature ichida ssenariylarni business rule bo‘yicha guruhlash mumkin. Masalan, “muddati tugagan token access bermaydi” bitta rule, uning turli misollari alohida scenario bo‘ladi. Bu feature faylni uzun step ro‘yxatidan domain hujjatiga aylantiradi.
Background
Bir nechta scenario uchun umumiy Given shartlari Background bo‘limida yozilishi mumkin. Unda faqat barcha ssenariyga haqiqatan umumiy qisqa context bo‘ladi. Ko‘p yashirin setup ssenariyni o‘qishni qiyinlashtiradi.
Scenario sifati
Yaxshi scenario mustaqil, deterministic va aniq natijali. “Va boshqa hamma narsa to‘g‘ri ishlaydi” kabi umumiy Then test qilinmaydi. Har misol bitta qoida haqida suhbatni davom ettiradi.
Manual BDD
Gherkin tool ishlatilmasa ham example workshop va Given–When–Then orqali requirement aniqlashtirish mumkin. BDDning qiymati sintaksisdan oldin jamoaviy tushunishda.
Bog‘liq tushunchalar
Behavior-Driven Development, Given-When-Then, Gherkin, Feature, Scenario, Step definition, Acceptance criteria, TDD, ATDD, Living documentation