Exception assertion — ma’lum amal belgilangan xato holatida kerakli exception turini va zarur bo‘lsa uning atributlarini chiqarishini tekshiruvchi test assertion’i. Negative testlarda faqat “xato bo‘ldi” deyish yetarli emas; xatoning contractga mos turi, kodi va qaysi amal sabab bo‘lgani tekshiriladi.
Tekshiruv chegarasi
Framework exception kutiladigan aynan kichik kod blokini o‘rab oladi. Juda katta blok ichida setup ham exception chiqarishi mumkin va test noto‘g‘ri sabab bilan o‘tadi.
with pytest.raises(InsufficientFunds) as error:
account.withdraw(500)
assert error.value.code == "insufficient_funds"
assert error.value.available == 120
Bu yerda faqat withdraw chaqiruvi exception kutiladigan hududda. Keyingi assertionlar structured ma’lumotni tekshiradi.
Tur va meros
Ko‘p tillarda assertion subclass exceptionni parent turga mos deb qabul qiladi. Exception kabi juda umumiy tur kutilsa NullPointer, connection xatosi yoki production defect ham testni o‘tkazib yuborishi mumkin. Eng aniq public exception turi tanlanadi.
Implementationga xos ichki exception API boundary’da boshqa errorga aylantirilishi mumkin. Service testida foydalanuvchiga ko‘rinadigan domain exception yoki HTTP error contract tekshiriladi, ichki database driver turi emas.
Xabar va atributlar
To‘liq message’ni tenglashtirish tarjima, punctuation yoki diagnostik detail o‘zgarganda testni mo‘rt qiladi. Agar message public contract bo‘lmasa, error code, field nomi va structured atributlar barqarorroq.
| Tekshiruv | Qachon ishlatiladi |
|---|---|
| Exception class | Xato kategoriyasi contract bo‘lsa |
| Error code | Machine-readable API uchun |
| Field/path | Validatsiya xatosi manzili uchun |
| Message qismi | Muhim diagnostik ma’no bo‘lsa |
| Cause chain | Xato wrapping siyosati uchun |
Regex orqali message tekshirilsa maxsus belgilar va locale hisobga olinadi. Juda umumiy contains("error") deyarli signal bermaydi.
Exception bo‘lmagan holat
Amal exception chiqarmasa test albatta yiqilishi kerak. Qo‘lda yozilgan quyidagi shakl xavfli: trydan keyin explicit failure bo‘lmasa test muvaffaqiyatli o‘tishi mumkin. Frameworkning raises, assertThrows yoki expect(...).toThrow konstruksiyasi bu xatoni oldini oladi.
Asinxron exception uchun future yoki coroutine’ni await qilish zarur. Faqat coroutine obyektini yaratish kodni bajarmaydi, shuning uchun test hech narsani tekshirmasligi mumkin. Promise rejection tegishli async matcher bilan tekshiriladi.
Side effectlar
Exception tashlanganida tizim qisman o‘zgargan bo‘lishi mumkin. Transaction rollback, file cleanup yoki event yuborilmagani ham contractning bir qismi bo‘lsa tekshiriladi. Masalan, to‘lov rad etilganda balans o‘zgarmasligi va receipt eventi chiqmasligi kerak.
Bu tekshiruvlar exception blokidan keyin bajariladi. State’ni faqat in-memory obyekt emas, haqiqiy persistence boundary’da ko‘rish integration test talab qilishi mumkin.
Cause va wrapping
Past qatlamdagi timeout domain service’da InventoryUnavailable sifatida wrap qilinishi mumkin. Public test yuqori darajadagi exceptionni tekshiradi; cause chain observability uchun saqlanishi mumkin. Raw SQL errorni tashqariga chiqarish abstraction va maxfiylikni buzadi.
Bir xil public error turli past sababdan kelishi mumkin. Test faqat muhim mappingni tekshiradi, implementation stack trace’ini to‘liq mahkamlamaydi.
Parametrlashtirish
Bir nechta noto‘g‘ri input bir xil exception contractiga ega bo‘lsa parametrized test ishlatiladi. Har case aniq ID va kutilgan code bilan beriladi. Barcha invalid inputni bitta katta testda ketma-ket chaqirish birinchi failuredan keyingi holatlarni yashiradi.
Bog‘liq tushunchalar
Assertion, Exception handling, Negative testing, Error code, Parametrized testing, Rollback, Test failure