GH GambleHub

Ünite vs Entegrasyon Testleri

1) Neden test türleri arasında ayrım

Testlerin doğru granülasyonu, gelişmeyi öngörülebilir kılar: Birim, mantık kusurlarını hızlı ve ucuz bir şekilde yakalar; Entegrasyon, modül demetlerini, gerçek taşımayı ve "tutkalı" kontrol eder. "Birlikte, regresyonu azaltırlar ve salımları hızlandırırlar.

2) Tanımlar ve sınırlar

Ünite testi

Küçük bir davranış birimini (işlev, sınıf, kullanım durumu) tek başına test eder.
Dış bağımlılıklar değiştirilir (mock/stub/fake).
Hızlı (ms-onlarca ms), deterministik.

Entegrasyon testi

Birkaç gerçek bileşenin etkileşimini denetler: veritabanı, broker (Kafka/RabbitMQ), HTTP/gRPC, dosya sistemi, önbellek.
Minimum mocs, gerçek protokoller.
Daha yavaş (yüzlerce ms-saniye), daha pahalı destek.

💡 Kural: "Proses/soket/DB'den geçer geçmez" - zaten entegrasyon sularındayız.

3) Test piramidi (buz boynuzu değil)

Vakıf: Birim (sayı olarak %70-80) - ucuz, hızlı.
Orta katman: Entegrasyon/Bileşen (%15-25) - kritik yollar ve sözleşmeler.
Üst: E2E/UX/Exploratory (%5-10) - en az yeterli.
Yanlarda: Statik Analiz/Lint/Tip kontrol ve kalite yükselteçleri olarak Mutasyon testi.

4) Birime ne verilecek ve entegrasyona ne

GörevYazıNe sebeple
Saf iş mantığı (doğrulamalar, komisyon hesaplamaları, anahtar idempotans)BirimHızlı, deterministik, birçok sınır değeri
Eşlemeler DTO↔model, serileştirme, ayrıştırmaBirimBirçok vaka, izole edilmesi kolay
Depolar/ORM SorgularıEntegrasyon (с testi DB)"Davranış" ORM ve SQL nüansları yalnızca canlı bir veritabanında görülebilir
HTTP sözleşmesi (durumlar, başlıklar, şemalar)Entegrasyon/SözleşmeCanlı bir HTTP + JSON Şeması/OpenAPI yığını gerekir
Saga/Outbox, Retras, Son TarihlerEntegrasyon/BileşenZamanlamalar, işlemsellik, broker
Hız sınırı в ağ geçidiEntegrasyonRedis/state/zaman aşımları
Ödeme webhook'ları (HMAC, tekrar)Entegrasyon/CDCİmzalar, saatler, ağ özellikleri

5) Veriler ve düzeltmeler

Birim

Satır içi kurgular/inşaatçılar (fabrika yöntemleri).
Sınır değerleri için tablo tabanlı testler.
Değişmezler için özellik tabanlı yaklaşım (örn. "debit toplamı = kredi toplamı").

Entegrasyon

Hermetik ortam: Testcontainers/Docker Yükseltmek 'postgres + redis + kafka + wiremock' oluşturun.
Veritabanında/önbellekte başlangıç tohumu ve sonrasında temizleme (işlem/geri alma, kesme).
Saatler/zamanlayıcılar sahte (kontrollü), aksi takdirde flacks.

6) Araçlar ve desenler

Alay/Saplamalar/Sahte/Casuslar:
  • Stub sabit bir cevaptır (ucuz).
  • Mock - etkileşimleri/çağrı sayısını kontrol edin.
  • Fake basitleştirilmiş bir uygulamadır (örneğin, In-Memory Repo).
  • Sözleşme testi (CDC): Pakt/Swagger tabanlı - müşteri beklentilerini düzeltin ve sağlayıcıyı kontrol edin.
  • WireMock/MockServer - Üçüncü taraf hizmetleri için HTTP taslakları.
  • Testcontainers bir "hayvanat bahçesi" olmadan yerel ve CI canlı DBs/broker vardır.

7) Örnekler

7. 1 Birim: Ödeme Idempotence (pseudocode)

python def test_idempotent_create_payment_returns_same_id():
repo = InMemoryPayments()
service = Payments(repo)

first = service. create(amount=100, key="abc")
second = service. create(amount=100, key="abc")

assert first. id == second. id assert repo. count() == 1

7. 2 Entegrasyon: Webhook İmza (HMAC) + Tekrar

bash docker-compose: app + redis + wiremock (PSP)
docker compose -f docker-compose. test. yml up -d pytest -m "integration and webhook" -q
Test:
  • WireMock bir 'X-Timestamp've bir imza ile bir olay verir.
  • Uygulama HMAC'yi kontrol eder, 'event _ id'ile tekilleştirir, 5 saniye sonra tekrarlayın çift oluşturmaz.
  • '200'ü kontrol ediyoruz ve sadece bir giriş var.

7. 3 CDC: Sağlayıcıya müşteri sözleşmesi

Müşteri bir Pakt oluşturur (bekleyen: 'POST/v1/ödeme' - '201'bir diyagram ile).
CI'daki sağlayıcı, standında sözleşmenin doğrulanmasını yürütür.

8) Hız, paralellik, pullar

Üniteler test başına <100 ms çalışmalıdır; Paket saniye.
Entegrasyon - konteynerler/portlarla paralel; Başlangıç geçişlerini kullanın.

Lapa lapa panzehir:
  • Kontrollü zaman (sahte saat),
  • "açık olayla" beklentiler, "uyku'değil,
  • Kararlı eşikler (deterministik olarak jitter testi ile retrai).

9) Kalite metrikleri

Kapsam (çizgiler/dallar): Eğilimi gözlemlemek için yararlıdır, ancak hedefi değil.
Mutasyon testi (PIT/Mutmut): Testlerin yanlış değişiklikleri "öldürüp öldürmediğini" gösterir - suikastçıların gerçek gücü.
Test süresi ve lapa lapa oranı: büyümede uyarılar.
Kusur muhafazası: Üretimden önce yakalanan böceklerin oranı.

10) CI/CD'ye gömme

Jobs: unit - integration - e2e (fan-out by service).
Bağımlılık önbelleği, veritabanı/dil/sürüme göre paralel matrisler.
Raporlar: JUnit/Allure + container log artifacts (damla için).
Kapı:'yeşil birim + kritik entegrasyon "- birleştirme koşulu; e2e - her gece.

Matris örneği (GitHub Eylemleri, fragman):
yaml strategy:
matrix:
db: [postgres14, postgres16]
steps:
- run: docker run -d --name db -e POSTGRES_PASSWORD=pw postgres:${{ matrix. db }}
- run: pytest -m "unit" -q
- run: pytest -m "integration" -q

11) Mikro Hizmetler ve Olaylar

Hizmet sözleşmeleri: OpenAPI/Protobuf sürümlüdür; Uyumluluk testleri (geriye dönük).

Olay odaklı:
  • Birim: etki alanı olay eşlemesi ve değişmezleri.
  • Entegrasyon: Gerçek bir komisyoncuda (Kafka) yayın/abonelik, giden/gelen kutusu anlambilimi, tam olarak bir kez taklit (en azından - idempotent).
  • Sıra dışı testler.

12) Entegrasyonda Veri ve izolasyon

Her test benzersiz bir şema/veritabanı (Testcontainers JDBC URL '? TC _ TMPFS =/var/lib/postgresql/data: rw ').
İşlemsel düzeltmeler (begin - run - rollback) temizliği hızlandırır.
Redis/cache için, anahtar öneki 'test: $ {RUN _ ID}:'ve' FLUSHDB'dir.

13) iGaming/Finansın Özellikleri

Para ve limitler: Değişmezler için özellik tabanlı testler (denge ≥ 0, toplam kısıtlamalar).
Düzenleyici: kayıt kontrolü (denetim günlüğü yazılır), değiştirilemez olaylar.
Ödemeler/PSP: HMAC/mTLS entegrasyon testleri, 'Retry-After', idempotency, dedup 'jti'.
Sorumlu oyun: eşik/bekleme süresi kural testleri; Sahte saat üzerinde "vchera - segodnya".

14) Antipatterns

DB/HTTP'yi yükselten "birimler" zaten entegrasyondur (katmanları karıştırır ve CI'yı yavaşlatır).
Boş ifadeler nedeniyle yüksek kapsama alanı ("kapalı, ancak kontrol edilmedi").
Bir sözleşmenin gerekli olduğu üçüncü taraf hizmetlerin Moki mantığı (güncellendiğinde kesilir).
Olay/durum beklentileri yerine 'uyku (5)'ile testler.
Paralel testler için ortak test veritabanı - ırk ve pul.

15) Prod Hazırlık Kontrol Listesi

Piramit, çalışma zamanına göre Unit/Integration/E2E ve hedef payların %'si olarak tanımlanır.

  • Birimler izole, hızlı, kapak sınır değerleri ve değişmezlerdir.
  • Entegrasyon, ortak durumlar olmadan hermetik bir ortam (Testcontainers/Compose) kullanır.
  • Sözleşme testleri (OpenAPI/Pact) CI'da doğrulanır.
  • Test verileri - yönetilen: tohum/geri dönüş/önekler, sahte saat.
  • Paralel çalışma, JUnit/Allure raporları, konteyner günlüğü eserler.
  • Metrikler: süre, lapa lapa oranı, mutasyon skoru; bozulmaya karşı uyarır.
  • Ödeme/webhook senaryoları: HMAC/mTLS, retrai, idempotency, deadup.
  • Strateji dokümantasyonu ve örnek test şablonları.

16) TL; DR

Ünite - maksimum mantık, minimum ortam; Entegrasyon - minimum moks, maksimum gerçekçilik. Piramidi tutun: Hızlı Birimler kusurların %80'ini yakalar, Entegrasyon demetleri ve sözleşmeleri onaylar. Hermetik kaplar, sözleşme testleri, sahte saat ve paralellik kullanın. Sadece kapsama alanını değil, aynı zamanda mutasyon skorunu ve lapa lapa oranını da ölçün. Özellikle ödeme/webhook yollarını kontrol edin: imzalar, retrays ve idempotency.

Contact

Bizimle iletişime geçin

Her türlü soru veya destek için bize ulaşın.Size yardımcı olmaya her zaman hazırız!

Entegrasyona başla

Email — zorunlu. Telegram veya WhatsApp — isteğe bağlı.

Adınız zorunlu değil
Email zorunlu değil
Konu zorunlu değil
Mesaj zorunlu değil
Telegram zorunlu değil
@
Telegram belirtirseniz, Email’e ek olarak oradan da yanıt veririz.
WhatsApp zorunlu değil
Format: +ülke kodu ve numara (örneğin, +90XXXXXXXXX).

Butona tıklayarak veri işlemenize onay vermiş olursunuz.