Parameterized test — bitta test mantiqini bir nechta kirish va kutilgan natija to‘plami bilan takror bajaradigan test turidir. U bir contractning boundary, normal va noto‘g‘ri qiymatlarini alohida test kodini ko‘paytirmasdan qamrab oladi. Har parametr to‘plami mustaqil test holati sifatida hisobot qilinadi.
Case tuzilishi
Eng oddiy case input va expected qiymatdan iborat. Murakkab holatda expected exception turi, error code yoki comparison strategy ham berilishi mumkin. Case nomi raqamdan ko‘ra ma’noni ifodalasa failure tez tushuniladi.
@ParameterizedTest(name = "{index}: {0}")
@CsvSource({"0, true", "7, true", "-1, false"})
void validatesQuantity(int value, boolean expected) {
assertEquals(expected, isValidQuantity(value));
}
CSV string va primitive qiymatlar uchun qulay. Domain object, locale yoki murakkab expected natija uchun method source type-safe argument yaratadi. External CSV katta reference datasetga mos, lekin uning versiyasi test kodi bilan birga boshqariladi.
Parametr manbalari
JUnit @ValueSource, @NullSource, @EmptySource, @EnumSource, @CsvSource va @MethodSource kabi manbalarni beradi. Custom ArgumentsProvider qayta ishlatiladigan domain case’larini yaratadi. Provider production database yoki networkga bog‘lanmasligi kerak, aks holda collection sekin va nondeterministic bo‘ladi.
Generator juda ko‘p case hosil qilsa test suite va report hajmi oshadi. Combinatorial inputlarda barcha kombinatsiyani tekshirish o‘rniga equivalence partition, boundary value yoki pairwise tanlash qo‘llanadi. Xavfsizlik va moliyaviy invariantlar uchun property-based testing ko‘proq tasodifiy qiymatni tekshirishi mumkin.
Izolyatsiya va lifecycle
Har invocation mustaqil setup va cleanup olishi kerak. Mutable obyekt bir nechta case orasida ulashilsa avvalgi test keyingisiga ta’sir qiladi. Parameter provider bir obyekt instance’ini qayta bersa, test uni nusxalashi yoki immutable qilish zarur.
Runner odatda har invocationni alohida test node qiladi. Parallel execution yoqilganda case’lar bir vaqtda ishlashi mumkin. Vaqtinchalik fayl, port va database identifikatori parametr yoki invocation ID bilan ajratiladi.
Failure ma’nosi
Test nomida inputning xavfsiz va qisqa tasviri ko‘rsatiladi. Juda uzun JSON reportni o‘qishni qiyinlashtiradi; case ID va alohida fixture fayl yaxshiroq. Secret, token yoki shaxsiy qiymat display namega chiqarilmaydi.
Bir case xato berganda qolgan invocationlar odatda davom etadi. Bu bir nechta boundary muammosini bitta run’da ko‘rsatadi. Ammo providerning o‘zi exception bersa collection to‘xtashi mumkin; provider validationi va source location xabari muhim.
Mos va nomos qo‘llanish
Bir xil amal va bir xil assertion strukturasi barcha case’larda saqlansa parametrization mazmunli. Agar ayrim case boshqa dependency, boshqa workflow va ko‘p shartli assertion talab qilsa ular alohida nomlangan testlarga ajratiladi. Test ichidagi katta if expected_type zanjiri bitta jadvalga ortiqcha mas’uliyat yuklanganini ko‘rsatadi.
Parameterized test implementation detali emas, contract variantlarini ifodalashi kerak. Masalan, parser uchun whitespace, Unicode digit va overflow alohida case bo‘lishi mumkin. Private helperning har branchini jadval bilan takrorlash esa public behaviorni emas, kod tuzilishini mustahkamlaydi.
Maintenance va coverage
Bug topilganda minimal reproducer yangi case sifatida qo‘shiladi. Bir xil ma’nodagi takror case’lar chiqariladi. Case soni o‘sishi coverage ko‘payganini anglatmaydi; har case yangi equivalence class yoki boundaryni ifodalashi kerak.
Mutation testing assertionlar noto‘g‘ri natijani ushlay olishini baholashi mumkin. Parametr jadvali talab hujjati bilan bog‘lansa, qaysi biznes qoidasi qaysi case bilan qamrab olingani aniq qoladi.
Bog‘liq tushunchalar
JUnit, Data-driven testing, Boundary value analysis, Test case, Property-based testing, Fixture, Test discovery