Expected value — test bajarilishidan oldin talab, spetsifikatsiya yoki oldindan hisoblangan model asosida kutiladigan natija. Test actual value’ni expected value bilan solishtirib, tekshirilayotgan kod contractga mos ishlaganini baholaydi. Kutilgan qiymat testning o‘zidan mustaqil mantiqqa tayanmasa, test mavjud xatoni takrorlashi mumkin.
Manbasi
Expected value biznes qoidasi, standart, API contract, matematik hisob yoki tasdiqlangan fixture’dan olinadi. Masalan, 10% soliq qo‘shilgan 150 birlik uchun 165 qiymat talabdan chiqariladi. Production funksiyaning o‘zini test ichida qayta chaqirib expected yaratish esa hech narsani mustaqil tekshirmaydi.
Reference implementation murakkab algoritmni tekshirishi mumkin, ammo u soddaroq va alohida ishonchli bo‘lishi kerak. Bir xil kutubxona yoki bir xil formulani ikki tomonda ishlatish common-mode xatoni yashiradi.
Qiymat shakllari
| Shakl | Misol |
|---|---|
| Scalar | Status code, son, boolean |
| Struktura | JSON obyekt yoki database row |
| Collection | Elementlar to‘plami va tartibi |
| Xato | Exception turi va error code |
| Side effect | Yaratilgan fayl yoki yuborilgan message |
| Approximation | Tolerance ichidagi floating-point natija |
Har natijani literal yozish shart emas. Predicate “barcha IDlar noyob” kabi xususiyatni tekshirishi, snapshot esa katta strukturaning tasdiqlangan nusxasini saqlashi mumkin.
Test oracle
Expected qiymatni to‘g‘ri aniqlaydigan manba test oracle deyiladi. Oddiy funksiyada literal oracle yetarli. Murakkab renderingda golden file, protocol parser’da rasmiy test vector, optimizatsiya algoritmida esa invariant va ma’lum kichik misollar ishlatiladi.
Oracle muammosi ayrim tizimlarda to‘g‘ri javobni oldindan hisoblashning o‘zi qiyinligini anglatadi. Property-based testing konkret barcha javoblar o‘rniga universal xususiyatlarni tekshiradi. Metamorphic testing kirish o‘zgarganda natija qanday munosabatda o‘zgarishini ko‘radi.
Tartib va normalization
Collection tartibi contractda muhim bo‘lsa expected ro‘yxat aynan tartibni saqlaydi. Tartib ahamiyatsiz bo‘lsa set yoki unordered comparison ishlatiladi. Aks holda database queryning tasodifiy tartibi flaky test keltiradi.
Timestamp, UUID, locale va absolute path kabi nondeterministik maydonlar nazorat qilinadi. Fake clock yoki fixed ID generator aniq expected beradi. Barcha dinamik maydonni olib tashlash esa muhim contractni yashirishi mumkin; faqat haqiqatan beqaror qism normallashtiriladi.
Expectedni yangilash
Test yiqilganda expectedni avtomatik o‘zgartirish xatoni “tasdiqlab” qo‘yishi mumkin. Avval actual o‘zgarish talabga mosligi tekshiriladi. Contract ataylab o‘zgargan bo‘lsa test, fixture va hujjat bir commitda yangilanadi.
Snapshot update’da diff code review qilinadi. Minglab snapshotning ommaviy o‘zgarishi muhim farqni yashiradi; semantik diff va kichik mantiqiy snapshotlar reviewni yaxshilaydi.
Expected xatolar
Negative test uchun expected value muvaffaqiyatli javob emas, balki aniq failure contract bo‘lishi mumkin. Masalan, noto‘g‘ri token uchun 401 status va invalid_token kodi kutiladi. To‘liq error matni tarjima yoki wording o‘zgarishiga sezgir bo‘lsa structured code tekshiriladi.
Exception kutilayotgan test amal exception bermasa albatta yiqilishi kerak. Oddiy try/exceptda failure qo‘yilmasa test jim muvaffaqiyatli o‘tib ketishi mumkin; frameworkning exception assertion’i xavfsizroq.
Mustaqillik va aniqlik
Expected test setup’dan tushunarli ko‘rinishi kerak. Yuz qatorli hisob ichida yashirilgan qiymat testni o‘qishni qiyinlashtiradi. Nomlangan fixture yoki jadval biznes holatni ifodalaydi.
Kutilgan qiymat ortiqcha ichki detallarni majburlamasligi lozim. Public response fieldlari contract bo‘lsa tekshiriladi; serializer ichki method chaqiruvlari expected natijaning bir qismi emas.
Bog‘liq tushunchalar
Actual value, Assertion, Test oracle, Golden file, Snapshot testing, Property-based testing, Test vector