Yadro sinovi strategiyasi

1) Qonunning

Piramida-kubok balansi. Baza - tezkor modul va kontrakt testlari; yuqorida - komponent va integratsiya; yuqorida - minimal, ammo qimmatli e2e qatlami.
Shift-left. Nuqsonni qanchalik tez tutsak (linter, statik tahlil, property-based), shunchalik arzon bo’ladi.
Deterministic by design. Vaqtni, tarmoqni, randomni va tashqi qaramlikni boshqaramiz.
Sifat iqtisodiyoti. Har qanday test - bu «sug’urta»: maqsad - jami xarajatlarni kamaytirish (nuqsonlar + testlarni kuzatib borish).
Tavakkalchilikka yo’naltirilganlik. Qoplama biznes-invariantlar va protokollarga (kontraktlar, idempotentlik, konsistentlik) jamlanadi.

2) Test sinovlari darajalari va javobgarlik zonalari

2. 1 Unit (modulli)

Sof mantiqni I/Osiz tekshirish.
Biz faqat chegaralarni (port/adapter) yuvamiz, ma’lumotlar uchun fabrikalardan foydalanamiz.
Tezkor (50-100 ms/test ≤), parallel.

2. 2 Contract (isteʼmolchi yetkazib beruvchi)

Xizmatlar o’rtasida API-shartnomalar (HTTP/gRPC/event) tuziladi.
Biz consumer-driven yondashuvidan foydalanamiz: shartnomalar VCSda saqlanadi, etkazib beruvchining CIda tekshiriladi.
Integratsiyalashgan e2e ning zaifligini kamaytiradi.

2. 3 Component (modul ustida, haqiqiy saqlash bilan)

Ushbu xizmatning bir qismini konteynerda haqiqiy DB/kesh bilan ishga tushirilmoqda (Testcontainers).
Sxemalar migratsiyasi, indekslar, tranzaksiyalar, blokirovkalarni tasdiqlaymiz.

2. 4 Integration/System (xizmatlar orasidagi uzluksiz yo’llar)

Izolyatsiya qilingan muhitda xizmatlar to’plamini ko’taramiz.
Biz tranzaksion, retraj, idempotent, xatolarga ishlov berish kabi invariantlarni tekshiramiz.

2. 5 E2E (eng kam «qimmatli» qatlam)

Haqiqiy protokollar va atrof-muhit «prodda bo’lgani kabi», lekin cheklangan ssenariy to’plami: to’lov → tasdiqlash → o’tkazish; ro’yxatdan o’tish → tekshirish → kirish.
Biz relizlar va regressiyalarni chiqarish uchun yuqori tavakkalchilikni qo’llaymiz.

3) Xamirpigodli arxitektura

Portlar/adapterlar (Hexagonal). Biznes yadro HTTP/SQL haqida bilmaydi; o’zaro bog’liqlik interfeyslar orqali joriy etiladi.
Vaqt/random in’eksiyasi. «Clock», «Random» - qaramlik; testlarda qayd etamiz.
Konfiguratsiya qilinadigan I/O qisqartmasi. Navbatlar, DB, KMS - test amalga oshirilgan interfeyslar orqali.
Funksional invariantlar. Biz post-shartlar va predikatlarni aniq shakllantiramiz - ularni sinab ko’rish va kuzatish osonroq.

4) Testlar uchun ma’lumotlar

Statik JSON-fikstura o’rniga fabrikalar/bilderlar: kamroq mo’rt.
Test oldidan idempotent sidlar va reset-xuk DB (migrations → truncate → seed).
Keys kataloglari: «normalar», «chetlar», «xatolar», «xaos».
Haqiqiy PD o’rniga sintetika: generatorlar, niqoblash, maxfiylik profillari.

5) Raqobat va idempotentlik

Poyga testlari (race): raqobat yozuvlari/zaxiralar/blokirovkalar.
Idempotent kalitlarni tekshirish (masalan,’(operation, external_id)’): takroriy chaqiruvlar holatni oʻzgartirmaydi.
Retray va taymautlar: vaqtinchalik xatolarda toʻgʻrilikni kafolatlaymiz.

dedupe_key = hash(op + external_id)
if exists(executions, dedupe_key): return previous_result else:
reserve(dedupe_key)
result = do_operation()
store(executions, dedupe_key, result)
return result

6) Vaqt, taymautlar, vaqt mintaqalari

Barcha saqlanadigan vaqtlar - UTC; testlarda’FixedClock’dan foydalaning.
DST-keyslarni (dubl/soat o’tkazib yuborish), «mahalliy kun» oynalarini sinovdan o’tkazamiz.
Taymautlarni monotonik soatlar bilan tekshiramiz; NTP tebranishini simulyatsiya qiling.

7) Barqarorlik va tartibsizlik

Fault-injection: tarmoq xatolari, 5xx, kechikishlar, qisman degradatsiya (kesh mavjud emas).
Pre-prod muhitidagi Chaos-testlar: uzilishlar, navbatlarning ortiqcha yuklanishi, BGP/Anycast uzilishlari (emulyatsiya).
Fallback siyosati va UX degradatsiyasi: testlar to’g’ri «graceful degradation» ni tasdiqlashi kerak.

8) Unumdorlik

Kritik algoritmlar uchun mikro-benchmarklar (CPU/alloc bilan).
Yuklash profillari: baseline (p50/p95), stress (cho’qqi), uzatilgan (soak) xotira oqishi uchun.
Regress-geytlar: agar p95 latentlik bazeline> X% dan yomonroq boʻlsa, build muvaffaqiyatsiz tugaydi.

9) Xavfsizlik va muvofiqlik

SAST/Lint: zaiflik/antipatternlarni qidirish.
DAST/IAST: stenddagi bazaviy ssenariylar (XSS/SQLi/SSRF-namunalar).
Secrets-scan: kod va artefaktlarda kalitlar/parollar mavjud emas.
Privacy-testlar: loglarda/trassalarda PD yo’qligi, «kelishuvlarni boshqarish» ga rioya qilish, tushirish uchun anonimlashtirish profillari.

10) Sifat metrikasi va SLO

Test pass rate va flaky index (beqaror testlar soni/hafta).

• 90-100% kritik yadro modullari uchun,
• 70-80% periferiya uchun (invariantlarga e’tibor qaratgan holda).
• Release risk score: jami: tanqidiy fayllardagi o’zgarishlar × benchmarklarning pasayishi × yangi flaky.
• Noto’g "ri budjet: tajribalar va relizlar chastotasi bilan prod-SLO (aptaym/xatolar) bog’lamasi.

11) CI/CD va geytlar

1. Lint/Format/TypeCheck

2. Unit + Property-based

3. Contract provider/consumer

4. Component (Testcontainers)

5. Integration + Perf smoke

6. Security (SAST/Secrets)

7. Build/Package + SBOM

8. Deploy to pre-prod + e2e + chaos smoke

Geytlar: shartnomalarning pasayishi, yashirlikning o’sishi, yangi tanqidiy zaifliklar.

Kesh va sharding: pipelinni parallelizm va inkremental progonlar hisobiga tezlashtiramiz (oʻzgartirilgan modullar boʻyicha).

12) Flaky-testlar: aniqlash va davolash

Avtopovtor + kvorum (2/3 progon).
Flake-pattern detektori: vaqtga/randomga/noaniq kutishlarga bog’liqlik.
SLA bilan karantin: test relizlarni to’sib qo’ymaydi, lekin N kunda tuzatilishi/qayta yozilishi shart.
Kritik yo’lning «yadrosi» dagi flakaga nisbatan nol bag’rikenglik.

13) Property-based, mutatsion va fazz-test

Property-based: xossalarni (kommutativlik, idempotentlik, monotonlik), chegara ma’lumotlari generatorlarini shakllantiramiz.
Mutation testing: testlarning «kuchini» o’lchaymiz (ular kiritilgan mutatsiyalarni o’ldiradimi).
Fuzzing: protokollar/parserlar/formatlar (JSON, Protobuf, CSV), ayniqsa xavfsizlik chegaralarida.

prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model

14) Kuzatuvchanlik va testlar bilan aloqa

Test trasterlari (loglarda trace-id): pre-prodga takrorlash qulay.
Metrik snapshotlar spektakl-progonda artefakt sifatida saqlanadi.
Loglarni nazorat qilish: sezgir maydonlarning yo’qligi, SLO doirasidagi loglarning o’lchami.

15) Hujjatlar va tartib-taomillar

Test Handbook: qayerda testlarni boshlash, fabrikalarni qanday yozish, shartnomalarni qanday yangilash kerak.
Runbooks: hodisani takrorlash, tezkor diagnostika, relizni qaytarish.
Invariantlar katalogi: tizim kafolatlari va tegishli test/alertlarga havolalar ro’yxati.

16) Arxitektorning chek-varaqasi

1. Yadro invariantlari va tanqidiy yo’llar tasvirlanganmi?
2. Test darajalari matritsasi va ularning SLO (vaqt, barqarorlik) bormi?
3. Kontraktlar yetkazib beruvchi va iste’molchida CIda versiyalashtiriladimi va tasdiqlanadimi?
4. Vaqt/rand/tarmoq testlarda (FixedClock, Fault-injector) boshqariladimi?
5. Testcontainers/izolyatsiya qilingan DB moslashtirildi, migratsiyalar tekshirilyaptimi?
6. Regressiya uchun spektakl-bazlayn va geyt bormi?
7. SAST/Secrets-scan va privacy-log tekshiruvi yoqilganmi?
8. Flaky hisobi olib borilyaptimi va tuzatish uchun SLA bormi?
9. Testlarning prod-SLO va noto’g’ri byudjet bilan aloqasi shaffof tarzda rasmiylashtirilganmi?
10. Runbook’va invariantlar katalogi hujjatlashtirilganmi?

Xulosa

Yadrosni sinovdan o’tkazish strategiyasi asboblar ro’yxati emas, balki arxitektura qobiliyati: testga yaroqli dizayn, qat’iy darajadagi ierarxiya, boshqariladigan ma’lumotlar, muvaffaqiyatsizlikka chidamlilik va CI/CD o’rnatilgan metriklar. Ta’riflangan amaliyotlar asosida jamoa tezkor va ishonchli fikr-mulohazalarga ega bo’ladi va relizlar oldindan aytib bo’ladigan va xavfsiz bo’ladi.