Çekirdek test stratejisi

1) İlkeler

Piramit-kupa dengesi. Baz - hızlı modüler ve kontrat testleri; yukarıda - bileşen ve entegrasyon; tepe noktasında minimal ama değerli e2e katmanı bulunur.
Vardiya-sol. Hatayı ne kadar erken yakalarsak (linter, statik analiz, mülk tabanlı), o kadar ucuz olur.
Tasarım olarak deterministik. Zaman, ağ, rastgele ve dış bağımlılıkları yönetiyoruz.
Kaliteli ekonomi. Herhangi bir test "sigorta'dır: Amaç toplam maliyetleri en aza indirmektir (kusurlar + test bakımı).
Risk yönelimi. Kapsam, iş değişmezleri ve protokolleri (sözleşmeler, idempotency, tutarlılık) üzerinde yoğunlaşmaktadır.

2) Test seviyeleri ve sorumluluk alanları

2. 1 Ünite (modüler)

I/O olmadan saf mantığı kontrol edin.
Sadece sınırları ıslatıyoruz (port/adaptör), veri için fabrikalar kullanıyoruz.
Hızlı (≤50 -100 ms/test), paralel.

2. 2 Sözleşme (tedarikçi ↔ tüketici)

Hizmetler arasındaki API sözleşmelerini (HTTP/gRPC/event) düzeltin.
Tüketici odaklı bir yaklaşım kullanıyoruz: sözleşmeler VCS'de saklanır, tedarikçinin CI'sında kontrol edilir.
Entegrasyon e2e'nin kırılganlığını azaltın.

2. 3 Bileşen (modülün üstünde, gerçek depolama ile)

Hizmetin bir kısmını bir konteynerde (Testcontainers) gerçek bir veritabanı/önbellek ile başlatıyoruz.
Şema geçişlerini, indeksleri, işlemleri, kilitleri doğrularız.

2. 4 Entegrasyon/Sistem (hizmetler arasında uçtan uca yollar)

İzole bir ortamda bir dizi hizmet sunuyoruz.
Uçtan uca değişmezleri kontrol ediyoruz: işlemsellik, retrai, idempotency, hata işleme.

2. 5 E2E (minimum "değerli" katman)

Gerçek protokoller ve çevre "satışlarda olduğu gibi", ancak sınırlı bir senaryo seti: ödeme - onay - gönderme; kayıt - doğrulama - giriş.
Serbest bırakma ve regresyon için yüksek riskli özellikler kullanıyoruz.

3) Test edilebilir mimari

Bağlantı noktaları/adaptörler (Altıgen). İş çekirdeği HTTP/SQL'i bilmiyor; Bağımlılıklar arayüzler aracılığıyla uygulanır.
Zaman/rastgele enjeksiyon. 'Saat', 'Rastgele' - bağımlılıklar; Düzelttiğimiz testlerde.
Yapılandırılabilir G/Ç soyutlaması. Kuyruklar, DB, KMS - test uygulamaları ile arayüzler aracılığıyla.
Fonksiyonel değişmezler. Postkonsisyonları ve yüklemleri açıkça formüle ediyoruz - test etmek ve izlemek daha kolay.

4) Testler için veriler

Statik JSON armatürleri yerine fabrikalar/inşaatçılar: daha az kırılganlık.
Idempotent tohumlar ve testten önce kanca DB sıfırlamak (göçler, truncate, tohum).
Vaka katalogları: "normlar", "kenarlar", "hatalar", "kaos".
Gerçek PD yerine sentetikler: jeneratörler, maskeleme, gizlilik profilleri.

5) Rekabet ve idempotans

Yarış testleri: Rekabetçi girişler/rezervler/kilitler.
Idempotent anahtarların denetlenmesi (örneğin, '(işlem, external_id)'): tekrarlanan çağrılar durumu değiştirmez.
Retrai ve zaman aşımları: Geçici hatalar durumunda doğruluğu garanti ediyoruz.

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) Zaman, zaman aşımları, zaman dilimleri

Depolanan tüm süreler UTC'dir; Testlerde 'FixedClock' kullanıyoruz.
DST durumlarını (kopyalar/saat özlüyor), "yerel gün" pencerelerini test ediyoruz.
Zaman aşımlarını monotonik bir saatle kontrol ediyoruz; NTP jitter simüle edin.

7) Esneklik ve kaos

Hata enjeksiyonu: ağ hataları, 5xx, gecikmeler, kısmi bozulma (önbellek kullanılamıyor).
Prod öncesi ortamda kaos testleri: düğümlerin kesilmesi, kuyrukların aşırı yüklenmesi, BGP/Anycast'in kırılması (emülasyon).
Fallback politikaları ve UX bozulması: testler doğru "zarif bozunmayı" doğrulamalıdır.

8) Performans

Kritik algoritmalar için mikro kriterler (CPU/alloc fiksasyonu ile).
Yük profilleri: taban çizgisi (p50/p95), stres (tepe), bellek sızıntıları için genişletilmiş (ıslatma).
Retress gates: p95 gecikmesi taban> X % değerinden daha kötüyse derleme başarısız olur.

9) Güvenlik ve uyumluluk

SAST/Lint: güvenlik açıklarını/antipatternleri arayın.
DAST/IAST: standdaki temel senaryolar (XSS/SQLi/SSRF örnekleri).
Secrets-scan: Kod ve yapaylarda anahtar/parola yok.
Gizlilik testleri: günlüklerde/izlerde PD eksikliği, "izin yönetimi'ne uygunluk, yüklemeler için anonimleştirme profilleri.

10) Kalite ve SLO metrikleri

Test geçiş oranı ve lapa lapa indeks.

• Kritik çekirdek modülleri için %90-100,
• Çevre için %70-80 (değişmezlere odaklanarak).
• Serbest bırakma risk puanı: bütünlük: kritik dosyalardaki değişiklikler × düşen kriterler × yeni lapa lapa.
• Hatalı bütçe: Prod-SLO'nun (çalışma süresi/hataları) deneyler ve serbest bırakma sıklığı ile bir kombinasyonu.

11) CI/CD ve Gates

1. Lint/Format/TypeCheck

2. Birim + Özellik tabanlı

3. Sözleşme sağlayıcı/tüketici

4. Bileşen (Testcontainers)

5. Entegrasyon + Perf dumanı

6. Güvenlik (SAST/Sırlar)

7. Yapı/Paket + SBOM

8. Ön prod + e2e + kaos dumanına dağıtın

Gates: düşen sözleşmelere, artan gecikmelere, yeni kritik güvenlik açıklarına son ver.

Önbellek ve sharding: paralellik ve artımlı çalıştırmalar nedeniyle boru hattını hızlandırır (değiştirilmiş modüller için).

12) Lapa lapa testler: tespit ve tedavi

Autorun + Quorum (koşuların 2/3'ü).
Flaki desen dedektörü: zaman/rastgele/örtük beklentilere bağımlılık.
SLA ile karantina: Test sürümleri engellemez, ancak N gün içinde düzeltilmeli/yeniden yazılmalıdır.
Kritik yolun "çekirdeğindeki" flucks'a sıfır tolerans.

13) Özellik tabanlı, mutasyon ve faz testi

Özellik tabanlı: özellikleri (komütativite, idempotency, monotonluk), sınır veri üreteçlerini formüle ediyoruz.
Mutasyon testi: Testlerin "gücünü" ölçeriz (uygulanan mutasyonları öldürüp öldürmediklerini).
Fuzzing: protokoller/ayrıştırıcılar/formatlar (JSON, Protobuf, CSV), özellikle güvenlik sınırlarında.

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

14) Gözlemlenebilirlik ve testlerle ilişki

Test izleri (günlüklerde trace-id): Pre-prod'da çoğaltmak uygundur.
Bir performans çalışması sırasında metriklerin anlık görüntüleri bir eser olarak saklanır.
Günlük denetimi: hassas alan yok, SLO içinde günlük boyutu.

15) Dokümantasyon ve prosedürler

Test El Kitabı: Hangi testlerin nerede yapılacağı, fabrikaların nasıl yazılacağı, sözleşmelerin nasıl güncelleneceği.
Runbooks: tekrarlama olayı, hızlı teşhis, serbest bırakma geri dönüşü.
Değişmeyen katalog: sistem garantilerinin listesi ve ilgili testlere/uyarılara referanslar.

16) Mimar kontrol listesi

1. Çekirdek değişmezler ve kritik yollar tarif?
2. Test seviyelerinin ve SLO'larının (zaman, kararlılık) bir matrisi var mı?
3. Sözleşmeler, tedarikçi ve tüketicide CI'da yayınlanır ve doğrulanır mı?
4. Testlerde zaman/rasgele/ağ kontrollü (FixedClock, Fault-enjektör)?
5. Yapılandırılmış Testcontainers/izole veritabanı, geçişler kontrol ediliyor mu?
6. Performans taban çizgileri ve regresyon kapıları var mı?
7. SAST/Secrets-tarama ve gizlilik günlüğü kontrolleri etkin mi?
8. Flaky kaydediliyor ve düzeltme için bir SLA var mı?
9. Testler ve prod-SLO ile hatalı bütçe arasındaki bağlantı şeffaf mı?
10. Runbook ve değişmeyen katalog belgelenmiş mi?

Sonuç

Çekirdek test stratejisi bir araç listesi değil, bir mimari beceridir: test edilebilir tasarım, katı seviye hiyerarşisi, yönetilen veriler, hata toleransı ve CI/CD'de yerleşik metrikler. Açıklanan uygulamaların ardından, ekip hızlı ve güvenilir geri bildirim alır ve yayınlar öngörülebilir ve güvenli hale gelir.