Nüvə test strategiyası
1) Prinsiplər
Piramidal-kubok balansı. Baza - sürətli modul və müqavilə testləri; yuxarıda - komponent və inteqrasiya; yuxarıda - minimal, lakin qiymətli qat e2e.
Shift-left. Qüsuru nə qədər tez tutsaq (linter, statik analiz, property-based), bir o qədər ucuzdur.
Deterministic by design. Vaxt, şəbəkə, random və xarici asılılıqları idarə edirik.
Keyfiyyət iqtisadiyyatı. Hər hansı bir test "sığorta 'dır: məqsəd ümumi xərcləri minimuma endirməkdir (qüsurlar + testlərin müşayiəti).
Risk yönümlülüyü. Örtük biznes invariantlarına və protokollara (müqavilələr, idempotentlik, konsistentlik) cəmləşir.
2) Test səviyyələri və məsuliyyət sahələri
2. 1 Vahid (modul)
I/O olmadan təmiz məntiqi yoxlayın.
Yalnız sərhədləri isladırıq (port/adapter), məlumat üçün fabriklərdən istifadə edirik.
Sürətli (≤ 50-100 ms/test), paralel.
2. 2 Contract (istehlakçı təchizatçısı)
Xidmətlər arasında API müqavilələri (HTTP/gRPC/event) qeydə alınır.
Biz consumer-driven yanaşma istifadə: müqavilələr VCS saxlanılır, CI təchizatçı yoxlanılır.
e2e inteqrasiya kövrəkliyini azaldır.
2. 3 Komponent (modul üzərində, real saxlama ilə)
Konteynerdə real DB/cache ilə xidmətin bir hissəsini işə salırıq (Testcontainers).
Sxemlərin, indekslərin, əməliyyatların, blokların miqrasiyasını təsdiqləyirik.
2. 4 Integration/System (xidmətlər arasında keçici yollar)
Təcrid olunmuş mühitdə xidmətlər dəstini qaldırırıq.
Tranzaksiya, retraj, idempotentlik, səhv emalı kimi alternativləri yoxlayırıq.
2. 5 E2E (minimum «qiymətli» təbəqə)
Real protokollar və mühit «prod kimi», lakin məhdud ssenari dəsti: ödəniş → təsdiq → kabel; qeydiyyat → yoxlama → giriş.
Buraxılışlar və reqressiya üçün yüksək riskli fiqurlardan istifadə edirik.
3) Xəmir yararlı memarlıq
Portlar/adapterlər (Hexagonal). Biznes nüvəsi HTTP/SQL haqqında bilmir; asılılıqlar interfeyslər vasitəsilə tətbiq olunur.
Vaxt/random enjeksiyonu. 'Clock', 'Random' - asılılıq; testlərdə qeyd edirik.
Konfiqurasiyalı I/O abstraksiyası. Növbələr, DB, KMS - test tətbiqləri olan interfeyslər vasitəsilə.
Funksional invariantlar. Post şərtləri və predikatları açıq şəkildə formalaşdırırıq - onları sınaqdan keçirmək və izləmək daha asandır.
4) Testlər üçün məlumatlar
Statik JSON fiksturları əvəzinə fabriklər/bilderlər: daha az kövrək.
Testdən əvvəl idempotent sidlər və reset-huk BD (migrations → truncate → seed).
Halların kataloqu: «normalar», «kənarlar», «səhvlər», «xaos».
Real PD əvəzinə sintetika: generatorlar, gizlilik profilləri.
5) Rəqabət və idempotentlik
Yarış testləri (race): rəqabətli qeydlər/ehtiyatlar/kilidlər.
İdempotent açarlarının yoxlanılması (məsələn, '(operation, external_id)'): təkrar zənglər vəziyyəti dəyişmir.
Retrauslar və vaxtlar: müvəqqəti səhvlər zamanı düzgünlüyə zəmanət veririk.
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 result6) Vaxt, taymaut, saat kəmərləri
Bütün saxlanılan vaxtlar - UTC; testlərdə 'FixedClock' istifadə edirik.
DST-cases (duple/saat keçidləri), «yerli gün» pəncərələrini sınaqdan keçiririk.
Vaxtları monotonik saatlarla yoxlayırıq; NTP titrəmə simulyasiya.
7) Sabitlik və xaos
Fault-injection: şəbəkə səhvləri, 5xx, gecikmələr, qismən deqradasiya (cache mövcud deyil).
Pre-prod mühitində Chaos testləri: düyünlərin bağlanması, növbələrin həddindən artıq yüklənməsi, BGP/Anycast boşluqları (emulyasiya).
Fallback siyasətləri və UX deqradasiyası: testlər düzgün «graceful degradation» təsdiq etməlidir.
8) Performans
Kritik alqoritmlər üçün mikro-bençmarklar (CPU/alloc fiksasiyası ilə).
Yükləmə profilləri: baseline (p50/p95), stress (pik), yaddaş sızması üçün uzadılmış (soak).
Reqress geytləri: p95 latentlik daha pis baseline> X% olarsa, build uğursuz olur.
9) Təhlükəsizlik və uyğunluq
SAST/Lint: zəifliklərin/anti-patternlərin axtarışı.
DAST/IAST: stenddə əsas ssenarilər (XSS/SQLi/SSRF nümunələri).
Secrets-scan: kodda və artefaktlarda açarların/parolların olmaması.
Privacy testləri: log/tracklerde PD olmaması, «razılıq idarəetməsinə» riayət edilməsi, boşaltmalar üçün anonimləşdirmə profilləri.
10) Keyfiyyət metrikası və SLO
Test pass rate və flaky index (qeyri-sabit testlərin sayı/həftə).
Coverage-hədəf:- 90-100% kritik nüvə modulları üçün,
- Periferiya üçün 70-80% (invariantlara diqqət yetirir).
- Release risk score: məcmu: kritik fayllarda dəyişikliklər × dəyər nişanlarının düşməsi × yeni flaky.
- Səhv büdcə: Prod-SLO (aptime/səhvlər) təcrübələr və buraxılış tezliyi ilə bir dəstə.
11) CI/CD və geytalar
Mərhələ matrisi: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
Geytalar: müqavilələrin düşməsi, gecikmə artımı, yeni kritik zəifliklər.
Cache & Charding: paralellik və inkremental qaçışlarla (dəyişdirilmiş modullarla) pipeline sürətləndiririk.
12) Flaky testlər: aşkar və müalicə
Avtopovtor + kvorum (2/3 qaçış).
Flake model detektoru: vaxt/random/qeyri-müəyyən gözləntilərdən asılılıq.
SLA ilə karantin: test buraxılışları bloklamır, lakin N gün düzəliş/yenidən yazılmalıdır.
Kritik yolun «nüvəsində» flakaya sıfır dözümlülük.
13) Property-based, mutasiya və faz test
Property-based: xüsusiyyətləri formalaşdırmaq (kommutativlik, idempotentlik, monotonluq), sərhəd məlumat generatorları.
Mutation testing: testlərin «gücünü» ölçün (onlar edilən mutasiyaları öldürür).
Fuzzing: protokollar/parserlər/formatları (JSON, Protobuf, CSV), xüsusilə təhlükəsizlik sərhədləri.
prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model14) Müşahidə və testlərlə əlaqə
Test izləri (loglarda trace-id): pre-prod-da oynatmaq rahatdır.
Performans qaçışında metrik snapshotlar - artefakt kimi saxlanılır.
Log Control: həssas sahələrin olmaması, SLO daxilində log ölçüsü.
15) Sənədləşmə və prosedurlar
Test Handbook: harada hansı testlər başlamaq, necə zavod yazmaq, müqavilələri yeniləmək üçün.
Runbooks: hadisə replay, sürətli diaqnostika, reliz geri.
İnvariantlar kataloqu: Sistem zəmanətlərinin və müvafiq testlərə/risklərə istinadların siyahısı.
16) Memarın yoxlama siyahısı
1. Nüvənin invariantları və kritik yolları təsvir olunur?
2. Test səviyyələrinin matrisi və onların SLO (vaxt, sabitlik) varmı?
3. Müqavilələr təchizatçı və istehlakçı tərəfindən CI versiyası və təsdiqlənir?
4. Vaxt/random/şəbəkə testlərdə idarə olunur (FixedClock, Fault-injector)?
5. Testcontainers/təcrid edilmiş DD, miqrasiya yoxlanılır?
6. Reqressiya üçün performans bazaları və qapılar varmı?
7. SAST/Secrets-scan və privacy-log yoxlamaları daxil?
8. Uçot flaky və düzəliş üçün SLA var?
9. Testlərin prod-SLO və səhv büdcə ilə əlaqəsi şəffafdır?
10. Runbook və invariant kataloqu sənədləşdirilib?
Nəticə
Nüvə test strategiyası alətlərin siyahısı deyil, memarlıq qabiliyyətidir: testə yararlı dizayn, ciddi səviyyə iyerarxiyası, idarə olunan məlumatlar, nasazlıq müqaviməti və CI/CD-də quraşdırılmış metriklər. Göstərilən təcrübələri izləyən komanda sürətli və etibarlı rəy alır və buraxılışlar proqnozlaşdırıla bilən və təhlükəsiz olur.