Contract testing — ikki tizim yoki komponent chegarasida so‘rov, javob va o‘zaro aloqa qoidalari kelishilgan shartnomaga mosligini tekshiradigan testlash usuli. Contract endpoint yo‘li, metod, schema, majburiy maydon, status kodi va ayrim semantik misollarni ifodalaydi. U butun end-to-end biznes oqimini emas, consumer va provider o‘rtasidagi moslikni maqsad qiladi.
Consumer va provider
Consumer xizmatdan foydalanadi, provider esa API yoki xabarni taqdim etadi. Consumer-driven contractda consumer o‘zi haqiqatan ishlatadigan interactionlarni test orqali yozadi. Contract broker yoki repositoryga publish qilinadi, provider buildi esa ularni o‘z implementatsiyasiga qarshi tekshiradi.
Bu model provider barcha mumkin bo‘lgan consumer ehtiyojini taxmin qilishidan ko‘ra aniqroq. Har contract consumer versiyasi va environmenti bilan bog‘lanadi. Provider deploydan oldin productiondagi faol consumer contractlariga mosligini tekshiradi.
HTTP contract
HTTP contract quyidagilarni qamrab olishi mumkin:
- request method, path, query va header;
- JSON maydonlari, turlari va majburiyligi;
- response status va content type;
- muhim body fieldlari va matcherlar;
- autentifikatsiya konteksti;
- xato javobining shakli.
Exact body equality mo‘rt bo‘lishi mumkin. Provider yangi optional maydon qo‘shsa, tolerant consumer buzilmasligi kerak. Matcher faqat consumerga zarur qismni tekshiradi. Biroq enumga noma’lum qiymat qo‘shilishi consumer parserini buzishi mumkin; compatibility qoidasi turga qarab belgilanadi.
Xabar contracti
Asinxron tizimda producer event schema va metama’lumotni e’lon qiladi, consumer uni qayta ishlaydi. Contract topic, event type, schema version va misol payloadni qamrab oladi. Xabar yetkazish tartibi, duplicate va retry semantikasi schema testidan tashqari bo‘lishi mumkin, shuning uchun operatsion contract ham hujjatlashtiriladi.
Schema registry backward, forward yoki full compatibility qoidalarini tekshirishi mumkin. Bu consumer-driven interaction test bilan aynan bir narsa emas, ammo ikkalasi birga ishlaydi.
Provider state
Contract misoli providerda ma’lum boshlang‘ich state talab qilishi mumkin: “ID 42 foydalanuvchi mavjud”. Provider verification shu state’ni fixture yoki setup hook bilan yaratadi, requestni bajaradi va javobni tekshiradi. State setup production endpointi bo‘lishi shart emas; u test muhiti boshqaruvidir.
Contract faqat mock serverga qarshi consumer testidan iborat qolsa, provider mosligi isbotlanmaydi. Ikkala tomon bajarishi va natija versiyalar bilan bog‘lanishi kerak.
Cheklovlari
Contract test service’larning individual protokol mosligini tekshiradi, lekin ko‘p bosqichli workflow, production routing, real latency va barcha dependencyni qamrab olmaydi. End-to-end va monitoring hanuz kerak. Contractda ifodalanmagan biznes qoida buzilishi mumkin.
Ko‘p mayda consumer contract provider pipeline vaqtini oshiradi. Eskirgan consumer versiyalari boshqarilib, faol deployment matrix saqlanadi. Provider breaking change qilsa, parallel API versiyasi yoki consumerlarni bosqichma-bosqich migratsiya qilish qo‘llanadi.
Version matriksi
Providerning yangi buildi faqat repositorydagi eng yangi contractga emas, hali productionda ishlayotgan consumer versiyalariga qarshi tekshiriladi. Deployment inventory qaysi consumer qaysi contract versiyasini ishlatayotganini ko‘rsatadi. Eski consumer butunlay olib tashlangach, uning contracti compatibility gate’dan chiqariladi.
Xavfsizlik contracti
Contract test authorization siyosatining tanlangan holatlarini qamrab olishi mumkin: token yo‘q, scope yetarli emas yoki boshqa tenant resursi. Biroq u penetration test o‘rnini bosmaydi. Provider state test credential va tenant isolationni to‘g‘ri yaratishi kerak; aks holda 200 javob schema bo‘yicha mos, lekin xavfsizlik jihatdan noto‘g‘ri bo‘lishi mumkin.
Bog‘liq tushunchalar
Consumer-driven contract, Provider, API schema, Schema registry, Integration testing, Backward compatibility