Test Unit vs Integration

1) Perché distinguere i tipi di test

La corretta granulazione dei test rende prevedibile lo sviluppo: Unit cattura i difetti logici in modo rapido e economico; Integration controlla i legamenti dei moduli, il trasporto reale e la colla. Insieme, riducono la regressione e accelerano i rilasci.

2) Definizioni e bordi

Test unit

Controlla l'unità di comportamento più piccola (funzione, classe, use-case) in isolamento.
Dipendenze esterne sostituite (mock/stub/fake).
Veloce (ms-10 mc), determinata.

Test integrazione

Verifica l'interazione di più componenti reali: database, broker (Kafka/RabbitMQ), HTTP/gRPC, file system, cache.
Minimo moka, protocolli reali.
Più lento (centinaia di ms-secondi), più costoso in termini di supporto.

3) La piramide di prova (non il cerchio di ghiaccio)

Base: Unità (70-80% in quantità) - economico, veloce.
Livello medio: Integration/Component (15-25%) - percorsi e contratti critici.
Superiore: E2E/UX/Explorer (5-10%) - minimo sufficiente.
Ai lati: Static Analysis/Lint/Type Check e Mutation testing come amplificatori di qualità.

4) Cosa dare Unità e cosa - Integrazione

5) Dati e ficsture

Unit

Inline ficsture/bilder (factory methods).
Test tabella (table-driven) per i valori limite.
Approccio property-based per gli invarianti (ad esempio, «importo dei debiti = importo dei prestiti»).

Integration

Ambiente hermetico: I Testontainers/Docker Compose alzano «postgres + redis + kafka + wiremock».
Seed iniziale nel database/cache e pulizia dopo (transazione/rollback, truncate).
Orologi/timer sono falsi (controllati), altrimenti flaconi.

6) Strumenti e pattern

• Stub è una risposta fissa (economica).
• Mok - Verifica interazioni/numero di chiamate.
• Fake - Implementazione semplificata (ad esempio In-Memory Repo).
• Contract testing (CDC): Pact/Swagger-based - Fissiamo le aspettative del client e controlliamo il provider.
• WireMock/MockServer - stub HTTP per servizi di terze parti.
• I Testcontainers sono OBD/broker viventi localmente e in CI senza «zoo».

7) Esempi

7. 1 Unità: idampotenza del pagamento (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 Integrazione firma webhook (HMAC) + ripetizione

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

• WireMock dà l'evento con «X-Timestamp» e firma.
• L'applicazione verifica HMAC, deduplica in «event _ id», la ripetizione in 5 secondi non crea la ripresa.
• Controlliamo il 200 e che la registrazione è la stessa.

7. 3 CDC contratto cliente per provider

Il client crea un Pact (in attesa di: 'POST/v1/payout's', con schema).
Il provider della CI sta controllando il contratto sul suo stand.

8) Velocità, parallelità, flaconcini

Unità deve funzionare <100 ms per il test; pacchetto - secondi.
Integration - parallelo su contenitori/porte utilizzare le migrazioni all'avvio.

• tempo controllato (fake clock),
• attesa per «evento esplicito» anziché «sleep»,
• soglie stabili (retrai con jitter test determinati).

9) Metriche di qualità

Coverage (righe/rami) - Utile per osservare la tendenza, ma non l'obiettivo.
Mutation testing (PIT/Mutmut) - Indica se i test «uccidono» i falsi cambiamenti, il vero potere dell'assurance.
Test duration e flaky rate: alert alla crescita.
Defect containment - Percentuale di bagagli intercettati prima della produzione.

10) Incorporazione in CI/CD

Jobs: unit → integration → e2e (fan-out servizi).
Cache delle dipendenze, matrici parallele per database/lingue/versioni.
Report: JUNnit/Allure + manufatti dei contenitori (in caso di cadute).
Gate: «green unit + integration critica» è una condizione di mago; e2e a 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) Microservizi ed eventi

I contratti di servizio sono versionati; Test di compatibilità (backward).

• Unità: mapping eventi di dominio e invarianti.
• Integration: pubblicazione/abbonamento in broker reale (Kafka), outbox/inbox semantico, exactly-once simulazione (almeno - idempotent).
• Test di retro/duplicati/riordinamento (out-of-order).

12) Dati e isolamento in Integration

Ogni test contiene uno schema/database univoco (Testcontainers JDBC URL '? TC _ TMPFS =/var/liv/postgresql/data: rw').
Le ficsture transazionali (begin→run→rollback) accelerano la pulizia.
Per Redis/cache è il prefisso chiave dì test: $ {RUN _ ID}: 'e' FLUSHSP'nel teardown.

13) Specificità iGaming/finanza

Soldi e limiti: test property-based per invarianti (saldo ≥ 0, vincoli totali).
Regolazione - Verifica registro (controllo-loga scritto), eventi invariati.
Pagamenti/PSP: test di integrazione HMAC/mTLS, «Retry-After», Idempoted, Deadup «jti».
Gioco responsabile: test delle regole di soglia/cooldown; «vchera→segodnya» su fake clock.

14) Antipattern

Le unità che alzano il database/NTCR sono già integrazioni (confondono i livelli e rallentano i CI).
Coverage elevato grazie a affermazioni vuote («coperto ma non verificato»).
Le logiche dei servizi di terze parti sono dove è necessario un contratto (si rompe durante l'aggiornamento).
Test con'sleep (5) 'invece delle aspettative di evento/condizione.
Database di prova generale per test paralleli di gara e flaconcini.

15) Assegno-foglio prod-pronto

• La piramide è definita con il% della percentuale di Unità/Integrazione/E2E e l'obiettivo di tempo di prova.
• Unità isolate, veloci, coprono valori limite e invarianti.
• Integration utilizza un ambiente hermetico (Testcontainers/Compose) senza bistecche condivise.
• I test contrattuali (OpenAPI/Pact) sono convalidati in CI.
• I dati dei test sono gestiti da seed/rollback/prefissi, fake clock.
• Test parallelo, rapporti JUNit/Allure, manufatti dei cassetti dei container.
• Metriche: duration, flaky rate, mutation score; Gli alert per il degrado.
• Script di pagamento/webhook: HMAC/mTLS, retrai, idampotenza, deducibilità.
• Documentazione strategica e esempi di modelli di test.

16) TL; DR

Unità: massima logica, minimo ambiente Integration è un minimo di moki, massimo realismo. Tenete la piramide: Unità veloci catturano l' 80% dei difetti, Integration conferma legamenti e contratti. Utilizzare contenitori hermetic, test contrattuali, fake clock e parallelismo. Misurare non solo coverage, ma anche mutation score e flaky rate. Verificare in particolare i percorsi di pagamento/webhook: firme, retrai e idempotenza.