Parametrized testing — bir xil test mantiqini turli kirish qiymatlari va kutilgan natijalar bilan qayta bajarish usuli. Har bir holat uchun alohida test funksiyasi yozish o‘rniga, test kodi bir marta tuziladi, ma’lumotlar esa jadval yoki parametrlar to‘plami sifatida beriladi. Shu sababli u chegaraviy qiymatlar, formatlar va xato holatlarini tizimli tekshirishda qo‘l keladi.
Test modeli
Parametrlashtirilgan test uch qismdan iborat: test tanasi, holatlar to‘plami va har holatni alohida testga aylantiruvchi runner. Masalan, sonning juftligini tekshiruvchi funksiya uchun 0, 2, -4 va 7 kiritmalari bitta test tanasidan o‘tadi. Runner odatda har qatorga mustaqil nom va natija beradi.
@pytest.mark.parametrize("value, expected", [
(0, True), (2, True), (-4, True), (7, False)
])
def test_is_even(value, expected):
assert is_even(value) is expected
Bu misolda bir qator yiqilsa, qolgan qatorlar baribir bajariladi. Oddiy sikl ichidagi assertion esa birinchi xatoda to‘xtab, keyingi holatlarni yashirishi mumkin.
Holatlarni tanlash
Parametrlar tasodifiy ko‘paytirilmaydi. Ular talabdagi ekvivalent sinflar va chegaralarni ifodalashi kerak. Matn uzunligini tekshiruvchi funksiya uchun bo‘sh satr, ruxsat etilgan eng qisqa va eng uzun satr, chegaradan bittaga oshgan satr hamda Unicode belgili satr mazmunli holatlardir.
| Holat turi | Maqsad |
|---|---|
| Oddiy qiymat | Asosiy yo‘lning ishlashini tekshirish |
| Chegaraviy qiymat | min, max va ularning yonini sinash |
| Noto‘g‘ri kirish | Xato turi yoki validatsiya javobini tekshirish |
| Maxsus format | null, Unicode, vaqt zonasi kabi holatni qamrash |
Kutilgan natija faqat qaytariladigan qiymat bo‘lmasligi mumkin. Exception turi, HTTP status, yaratilgan yozuvlar yoki tashqi xizmatga yuborilgan chaqiruv ham parametrga kiritiladi.
Identifikatsiya va diagnostika
Test hisobotida case_7 kabi noaniq nomlar tahlilni sekinlashtiradi. Framework qo‘llasa, holatlarga empty_input, upper_boundary yoki expired_token kabi mazmunli ID beriladi. Maxfiy ma’lumot parametr nomida ko‘rsatilmaydi, chunki CI hisobotlari va loglar uzoq saqlanishi mumkin.
Katta obyektlar parametrga to‘liq joylashtirilsa, test kodi o‘qilmay qoladi. Bunday obyektlar fixture yoki factory yordamida quriladi, parametr esa faqat farqlanuvchi atributlarni bildiradi. Kutilgan va amaldagi qiymat orasidagi diff ham ixcham bo‘lishi lozim.
Kombinatsiyalar va hajm
Uch parametrning har birida o‘ntadan qiymat bo‘lsa, Cartesian product mingta test beradi. Barcha kombinatsiya zarur bo‘lmasa, representative pairwise to‘plam yoki aniq xavfga asoslangan holatlar tanlanadi. Aks holda test vaqti oshadi, bir xil sababdan yuzlab failure paydo bo‘ladi.
Mustaqil parametrlar product bilan, mantiqan bog‘langan qiymatlar esa tayyor tuple qatorlari bilan beriladi. Masalan, valyuta kodi va o‘nlik aniqligi mustaqil emas; noto‘g‘ri juftlik testning o‘zini ma’nosiz qiladi.
Fixture va tashqi holat
Har parametr bajarilishidan oldin test muhiti izolyatsiya qilinadi. Database yozuvlari, vaqt, fayl va mock holati bir qatordan boshqasiga oqib o‘tmasligi kerak. Runner fixture’ni parametr scope’iga mos yaratib, testdan keyin tozalaydi.
Parametrlar tashqi CSV yoki JSONdan o‘qilishi mumkin, biroq bunday fayl test kodi bilan birga versiyalanadi va schema bo‘yicha tekshiriladi. Production ma’lumotini bevosita ulash testni takrorlanmaydigan va maxfiylikka xavfli qiladi.
Qo‘llanish chegarasi
Har bir holat boshqa setup, boshqacha amal yoki alohida biznes ma’nosiga ega bo‘lsa, bitta parametrli test haddan tashqari abstraktlashadi. Bunday vaziyatda nomlangan alohida testlar tushunarliroq. Parametrizatsiya bir xil xatti-harakatni ma’lumotlar orqali ifodalaganda samarali; turli ssenariylarni bitta funksiyaga majburan joylash uning foydasini kamaytiradi.
Bog‘liq tushunchalar
Unit testing, Test case, Fixture, Boundary value analysis, Data-driven testing, Property-based testing