Unit vs Integrationstests

1) Warum zwischen Testtypen unterscheiden

Die richtige Granulierung der Tests macht die Entwicklung vorhersehbar: Unit fängt Logikfehler schnell und günstig auf; Integration prüft Modulbündel, realen Transport und „Kleber“. Gemeinsam reduzieren sie Rückschritte und beschleunigen Freigaben.

2) Definitionen und Grenzen

Unit-Prüfung

Prüft eine kleine Verhaltenseinheit (Funktion, Klasse, Use-Case) isoliert.
Externe Abhängigkeiten werden ersetzt (mock/stub/fake).
Schnell (ms-zehnt ms), deterministisch.

Integrationstest

Überprüft das Zusammenspiel mehrerer realer Komponenten: DB, Broker (Kafka/RabbitMQ), HTTP/gRPC, Dateisystem, Cache.
Minimale Moks, echte Protokolle.
Langsamer (Hunderte von ms-Sekunden), teurer in der Unterstützung.

3) Testpyramide (nicht Eishorn)

Basis: Einheit (70-80% durch Quantität) - billig, schnell.
Mittlere Schicht: Integration/Komponente (15-25%) - kritische Pfade und Verträge.
Top: E2E/UX/Exploratory (5-10%) - minimal genug.
An den Seiten: Statische Analyse/Lint/Typenprüfung und Mutationsprüfung als Qualitätsverstärker.

4) Was geben Einheit und was - Integration

5) Daten und Fiktionen

Unit

Inline-Fixturen/-Bildner (Fabrikmethoden).
Tabellarische Tests (table-driven) für Grenzwerte.
Eigenschaftsbasierter Ansatz für Invarianten (z.B. „Lastschriftbetrag = Gutschriftbetrag“).

Integration

Hermetische Umgebung: Testcontainer/Docker Compose erheben 'postgres + redis + kafka + wiremock'.
Initialer Seed im DB/Cache und Bereinigung danach (Transaktion/Rollback, Truncate).
Uhren/Timer sind Fake (kontrolliert), sonst Flacks.

6) Werkzeuge und Muster

• Stub ist eine feste Antwort (billig).
• Mock - Überprüfen Sie Interaktionen/Anzahl der Anrufe.
• Fake ist eine vereinfachte Implementierung (z.B. In-Memory Repo).
• Vertragsprüfung (CDC): Pact/Swagger-based - wir erfassen die Erwartungen des Kunden und prüfen den Anbieter.
• WireMock/MockServer - HTTP-Stubs für Dienste von Drittanbietern.
• Testcontainer sind Live-DBs/Broker lokal und im CI ohne „Zoo“.

7) Beispiele

7. 1 Einheit: Idempotenz der Zahlung (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 Integration: Webhook-Signatur (HMAC) + Wiederholung

bash docker-compose: app + redis + wiremock (PSP)
docker compose -f docker-compose. test. yml up -d pytest -m "integration and webhook" -q

• WireMock verschenkt das Event mit 'X-Timestamp' und Signatur.
• Die Anwendung überprüft HMAC, dedupliziert durch 'event _ id', eine Wiederholung nach 5 Sekunden erzeugt keinen Take.
• Wir überprüfen '200' und dass es nur einen Eintrag gibt.

7. 3 CDC: Vertrag des Kunden mit dem Anbieter

Der Kunde bildet einen Pact (Erwartung: 'POST/v1/payout' → '201' mit Schema).
Der Anbieter im CI fährt die Vertragsprüfung an seinem Stand durch.

8) Geschwindigkeit, Parallelität, Flakes

Einheiten sollten <100 ms pro Test arbeiten; Paket - Sekunden.
Integration - parallel zu Containern/Häfen; Migrationen beim Start verwenden.

• kontrollierte Zeit (Fake Clock),
• Erwartungen „für ein klares Ereignis“ und nicht „Schlaf“,
• stabile Schwellen (Retrays mit Jitter deterministisch testen).

9) Qualitätsmetriken

Coverage (Zeilen/Zweige): nützlich, um einen Trend zu beobachten, aber nicht das Ziel.
Mutationstests (PIT/Mutmut): Zeigt, ob Tests falsche Änderungen „töten“ - die wahre Stärke von Assurence.
Testdauer und Flakrate: Alerts beim Wachstum.
Defect containment: Der Anteil der vor der Produktion abgefangenen Fehler.

10) Einbettung in CI/CD

Jobs: Einheit → Integration → e2e (Fan-out für Dienste).
Abhängigkeitscache, parallele Matrizen nach DB/Sprachen/Versionen.
Berichte: JUnit/Allure + Container Logartefakte (bei Stürzen).
Gate: „grüne Einheit + kritische Integration“ - eine Bedingung der Perge; e2e - auf nightly.

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) Microservices und Events

Serviceverträge: OpenAPI/Protobuf werden versioniert; Kompatibilitätstests (Backward).

• Unit: Mapping von Domänenereignissen und Invarianten.
• Integration: Veröffentlichung/Abonnement in einem echten Broker (Kafka), outbox/inbox Semantik, exactly-once Nachahmung (mindestens - idempotent).
• Retray-/Duplikat-/Reorder-Tests (Out-of-Order).

12) Daten und Isolation in der Integration

Jeder Test → ein eindeutiges Schema/DB (Testcontainers JDBC URL'? TC _ TMPFS =/var/lib/postgresql/data: rw').
Transaktionale Fixturen (begin→run→rollback) beschleunigen die Reinigung.
Für Redis/Cache ist das Schlüsselpräfix' test: $ {RUN _ ID}: 'und' FLUSHDB 'in teardown.

13) Spezifität von iGaming/Finanzen

Geld und Grenzen: eigenschaftsbasierte Invariantentests (Saldo ≥ 0, Gesamtgrenzen).
Regulierung: Überprüfung der Protokollierung (Audit-Log wird geschrieben), unveränderliche Ereignisse.
Zahlungen/PSP: HMAC/mTLS Integrationstests, 'Retry-After', idempotency, dedup 'jti'.
Verantwortungsvolles Spielen: Tests der Schwellen-/Coulddowns-Regeln; „vchera→segodnya“ auf der Fake-Uhr.

14) Antipatterns

Die „Einheiten“, die die DB/NTTR anheben, sind bereits Integration (verwirren Schichten und verlangsamen CI).
Hohe Deckung durch leere Aussagen („abgedeckt, aber nicht überprüft“).
Moki Logik von Drittanbietern Dienstleistungen, wo Sie einen Vertrag benötigen (bricht mit dem Upgrade).
Tests mit 'Schlaf (5)' anstelle der Erwartungen des Ereignisses/Bedingung.
Gemeinsame Test-DB für parallele Tests → Rennen und Flyes.

15) Checkliste Prod-Ready

• Die Pyramide ist definiert als:% der Unit/Integration/E2E und das Ziel nach Laufzeit.
• Einheiten sind isoliert, schnell, decken Randwerte und Invarianten ab.
• Integration verwendet eine hermetische Umgebung (Testcontainer/Compose), ohne gemeinsame Elemente.
• Vertragstests (OpenAPI/Pact) werden im CI verifiziert.
• Testdaten - überschaubar: Saatgut/Rollback/Präfixe, Fake-Uhr.
• Parallellauf, JUnit/Allure-Berichte, Container-Logartefakte.
• Metriken: duration, flaky rate, mutation score; Alerts auf Degradation.
• Payment/Webhook-Szenarien: HMAC/mTLS, Retrays, Idempotenz, Dedup.
• Strategiedokumentation und Beispiele für Testvorlagen.

16) TL; DR

Einheit - Maximum der Logik, Minimum der Umgebung; Integration - ein Minimum an Moks, ein Maximum an Realismus. Halten Sie die Pyramide: Schnelle Einheiten fangen 80% der Mängel auf, Integration bestätigt Bündel und Verträge. Verwenden Sie hermetische Container, Vertragstests, Fake Clock und Parallelität. Messen Sie nicht nur coverage, sondern auch mutation score und flaky rate. Überprüfen Sie insbesondere die Zahlungs-/Webhook-Pfade: Signaturen, Retrays und Idempotenz.