Backend Test Stratejileri
Backend testleri tek bir “test edildi” sinyali değildir; hızlı unit testten gerçek dependency ve failure davranışına kadar farklı güvence katmanlarıdır. Her test, yakaladığı riski ve üretimden ne kadar farklı olduğunu açıkça belirtmelidir.
Hızlı Karar
| Risk | Test | Dikkat |
|---|---|---|
| İş kuralı | Unit test | Hızlı ve deterministic olmalı |
| API/DB entegrasyonu | Integration test | Gerçek schema ve migration kullan |
| Tüketici sözleşmesi | Contract test | Provider/consumer sürümünü doğrula |
| Kullanıcı akışı | End-to-end | Az sayıda kritik senaryo seç |
| Kapasite | Load/stress test | Gerçekçi workload ve limit tanımla |
| Güvenlik | Security test/scan | False positive ve exception yönetimi |
Üretim Kontrol Listesi
- Problem: Hangi failure mode veya regression yakalanmak isteniyor?
- Çözüm: Test data, environment, oracle, timeout ve cleanup davranışı tanımlı mı?
- Trade-off: Daha gerçekçi test daha yavaş ve pahalıdır; yalnız mock'a güvenmek riski gizler.
- Hata durumu: Flaky test, shared state, migration mismatch, external outage ve false security finding ele alınmalı.
- Ölçüm: Pass rate, duration, flake rate, coverage by risk, escaped defect ve deployment gate izlenmeli.
- Güvenlik/maliyet: Secret ve PII fixture'a girmemeli; load test production'dan izole olmalı.
Test Katmanları
Unit ve integration
Unit test domain/service mantığını dependency mock veya fake ile hızlı doğrular. Integration test gerçek Spring context, database schema, migration, queue veya HTTP client davranışını sınar. Test container veya ephemeral dependency kullanılıyorsa sürüm ve cleanup deterministik olmalıdır.
Contract ve mocking
Consumer-driven contract test, tüketicinin kullandığı request/response beklentisini provider'a doğrulatır. Mock server sözleşmeden üretilmeli; mock ile integration test aynı şey değildir. Contract ayrıntıları için API Contract ve Tooling sayfasına bakılabilir.
End-to-end
E2E testleri login, authorization, create/update, async completion ve failure recovery gibi kritik iş akışlarını gerçek sınırlar üzerinden çalıştırır. Test sayısı küçük tutulmalı; her katmandaki ayrıntıyı E2E'ye taşımak pipeline'ı kırılganlaştırır.
Load, Stress ve Chaos
Load test beklenen trafik altında latency/throughput hedefini ölçer. Stress test kapasite sınırını ve graceful degradation davranışını arar. Spike test ani trafik, soak test uzun süreli leak/queue birikimi, chaos test ise kontrollü dependency/instance failure davranışını doğrular.
Her deney için workload, duration, ramp, success threshold, blast radius, stop condition ve veri temizliği yazılmalıdır. CPU veya request sayısı tek başına başarı ölçütü değildir; SLO, queue age, error budget ve kullanıcı etkisi birlikte değerlendirilir.
CI/CD Otomasyonu
Önerilen pipeline sırası:
- Format/lint ve hızlı unit test.
- Build ve migration doğrulaması.
- Integration ve contract test.
- Security/dependency scan.
- İzole staging'de smoke/E2E.
- Canary veya blue-green sonrası SLO gate.
Flaky test quarantined olsa bile owner ve düzeltme tarihi olmalı. Test sonucu, artifact sürümü ve ortam bilgisi birlikte saklanmalıdır.
Test Verisi ve Diagnostik
Fixture'lar minimum, anonim ve tekrar üretilebilir olmalı. Clock, random ID, external response ve queue zamanı injectable yapılırsa test deterministic hale gelir. Hata olduğunda request ID, trace ID, test adı, artifact ve dependency log referansı sunulmalıdır.
Test kapsamı satır sayısı değil risk kapsamasıdır. Mutlu yolun yanında timeout, duplicate delivery, stale read, unauthorized object, retry exhaustion, partial failure ve rollback senaryoları bulunmalıdır.