Step definition — BDD spetsifikatsiyasidagi tabiiy tilga yaqin qadamni bajariladigan dastur kodiga bog‘laydigan funksiya yoki metoddir. U Given, When yoki Then satrining matnini moslashtiradi, zarur amalni bajaradi va natijani tekshiradi. Feature fayl shu qatlam orqali test tizimi, API, brauzer yoki domen kodi bilan ulanadi.
Matnni kodga moslash
BDD vositasi qadam matnini ro‘yxatdan o‘tgan patternlar bilan solishtiradi. Pattern oddiy ibora, parametrli expression yoki regular expression bo‘lishi mumkin. Masalan, “hisobda 50000 so‘m mavjud” qadami son parametrini ajratib, hisob obyektini tayyorlaydigan funksiyaga uzatadi.
Hech bir pattern mos kelmasa qadam undefined deb belgilanadi. Bir nechta definition bir xil satrga mos tushsa ambiguous holati paydo bo‘ladi; vosita qaysi kodni tanlashni bilmaydi. Patternlarni aniq chegaralash va bir xil ma’nodagi qadamlarni takror yaratmaslik bu muammoni kamaytiradi.
Qadam turlarining vazifasi
Texnik jihatdan ayrim frameworklar Given, When va Then uchun bir xil matching mexanizmini ishlatadi. Semantik farq esa muhim:
- Given test kontekstini tayyorlaydi;
- When tekshirilayotgan hodisani ishga tushiradi;
- Then kuzatiladigan natijani tasdiqlaydi.
Then ichida yangi biznes amali bajarilsa, senariyning sabab–natija tuzilishi xiralashadi. Given ichidagi assertion ham tayyorlash xatosini talab buzilishi bilan aralashtirishi mumkin. Qadam roliga mos kod hisobotni tushunarli qiladi.
Holat almashinuvi
Bitta scenario qadamlari ma’lumotni umumiy scenario context orqali ulashishi mumkin. Masalan, When qaytargan HTTP javobi contextga yoziladi, Then esa uning status va tanasini tekshiradi. Global o‘zgaruvchi ishlatilsa, parallel senariylar bir-birining holatini buzishi mumkin. Context odatda har scenario uchun alohida yaratiladi va yakunda tozalanadi.
Dependency injection yordamida API mijoz, vaqt provayderi yoki test ma’lumotlari fabrikasi step klassiga beriladi. Bu bog‘liqliklarni yashirmaydi va unit tekshiruvini yengillashtiradi. Biroq step definition ichida katta biznes mantiqini qayta yozish kerak emas; u imkon qadar tizimning haqiqiy kirish nuqtasini chaqiradi.
Abstraksiya va qayta foydalanish
Juda texnik qadam, masalan aniq CSS selektorni bosish, feature faylni interfeys tuzilishiga bog‘laydi. Domen darajasidagi “mijoz buyurtmani tasdiqlaydi” qadami esa sahifa obyektiga murojaat qilishi mumkin. UI o‘zgarsa step yoki page object yangilanadi, biznes senariysi saqlanib qoladi.
Qayta foydalanish maqsadida haddan tashqari universal qadam yaratish ham muammo tug‘diradi. O‘nlab parametrli “obyektga amal bajaraman” qadami o‘qishni qiyinlashtiradi va domen tilini yo‘qotadi. Bir xil biznes ibora bir xil ma’noni anglatsa qayta ishlatiladi; tashqi ko‘rinishi o‘xshash, lekin semantikasi boshqa amallar alohida qoladi.
Xatolar va diagnostika
Assertion muvaffaqiyatsiz bo‘lsa, xabar kutilgan va amaldagi qiymatni ko‘rsatishi kerak. Brauzer testida screenshot, tarmoq javobi yoki sahifa manzili qo‘shimcha dalil bo‘lishi mumkin. Maxfiy token, parol va shaxsiy ma’lumot diagnostikaga to‘liq yozilmaydi.
Timeoutlar aniq qatlamda boshqariladi. Doimiy sleep testni sekin va beqaror qiladi; kerakli hodisa yoki elementni cheklangan muddat kutish ma’qul. Tashqi servis xatosini mahsulot talabining buzilishi sifatida ko‘rsatmaslik uchun muhit tekshiruvi va aniq xato turlari qo‘llanadi.
Texnik qarzdorlik
Featurelar ko‘paygani sari o‘xshash pattern, ishlatilmaydigan definition va sekin yordamchi kod to‘planishi mumkin. Linter va test vositasi undefined yoki ambiguous qadamlarni aniqlaydi. Definitionlar domen bo‘yicha modulga ajratilib, umumiy setup hooklari nazorat qilinadi. Har qadamning bajarilish vaqti kuzatilsa, sekin test to‘plamining asosiy sabablari topiladi.
Bog‘liq tushunchalar
Behavior-Driven Development, Scenario, Gherkin, Cucumber Expression, Test fixture, Assertion