Tests d'intégration unitaire vs

1) Pourquoi distinguer les types de tests

La bonne granulation des tests rend le développement prévisible : Unit attrape les défauts de logique rapidement et à bas prix ; L'intégration vérifie les ligaments des modules, le transport réel et la « colle ». Ensemble, ils réduisent la régression et accélèrent les sorties.

2) Définitions et limites

Test unitaire

Vérifie une petite unité de comportement (fonction, classe, use-case) isolée.
Les dépendances externes ont été remplacées (mock/stub/fake).
Rapide (ms-dizaines de ms), déterministe.

Test d'intégration

Vérifie l'interaction de plusieurs composants réels : Base de données, courtier (Kafka/RabbitMQ), HTTP/gRPC, système de fichiers, cache.
Minimum de mouettes, protocoles réels.
Plus lent (des centaines de ms-secondes), plus cher pour le support.

3) Pyramide d'essai (pas corne de glace)

Base : Unité (70-80 % en quantité) - bon marché, rapide.
Couche moyenne : Integration/Component (15-25 %) - chemins critiques et contrats.
Haut : E2E/UX/Exploratory (5-10 %) - minimum suffisant.
Sur les côtés : Static Analysis/Lint/Type check et Mutation testing comme amplificateurs de qualité.

4) Que donner à l'Unité et que - Intégration

5) Données et fictions

Unit

Inline fiches/bilders (méthodes d'usine).
Tests tabulaires (table-driven) pour les valeurs limites.
Approche basée sur la propriété pour les invariants (par exemple, « montant des débits = montant des crédits »).

Integration

Environnement hermétique : Testcontainers/Docker Composite soulève 'postgres + redis + kafka + wiremock'.
Seed initial dans la base de données/cache et nettoyage après (transaction/rollback, truncate).
Les horloges/minuteries sont fausses (contrôlées), sinon les flacons.

6) Outils et modèles

• Stub est une réponse fixe (bon marché).
• Mock - Vérifie les interactions/nombre d'appels.
• Fake est une implémentation simplifiée (par exemple In-Memory Repo).
• Test de contrat (CDC) : Pact/Swagger-based - nous enregistrons les attentes du client et vérifions le fournisseur.
• WireMock/MockServer - bouchons HTTP pour les services tiers.
• Les Testcontainers sont des OBD/courtiers vivants localement et en IC sans « zoo ».

7) Exemples

7. 1 Unité : Idempotence de paiement (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 Intégration : Signature du Webhook (HMAC) + répétition

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

• WireMock donne l'événement avec « X-Timestamp » et la signature.
• L'application vérifie HMAC, déduplie par 'event _ id', la répétition dans 5 secondes ne crée pas de prise.
• On vérifie « 200 » et que l'enregistrement est seul.

7. 3 CDC : contrat client avec le fournisseur

Le client forme un Pact (attente : 'POST/v1/payout' → '201' avec le circuit).
Le fournisseur de CI lance la vérification du contrat sur son stand.

8) Vitesse, parallèle, flocons

L'unité doit fonctionner <100 ms par test ; paquet - secondes.
Intégration - paralléliser les conteneurs/ports ; utiliser les migrations au démarrage.

• temps contrôlé (fake clock),
• les attentes « par événement explicite », et non « sleep »,
• seuils stables (retraits avec jitter à tester de manière déterministe).

9) Métriques de qualité

Coverage (lignes/branches) : utile pour observer la tendance, mais pas le but.
Mutation testing (PIT/Mutmut) : montre si les tests « tuent » les faux changements - le pouvoir réel de l'assurance.
Test de durée et taux de flaky : alertes à la croissance.
Defect containment : proportion de bogues interceptés avant la production.

10) Incorporation dans CI/CD

Jobs : unité → intégration → e2e (fan-out par service).
Cache de dépendances parallèles aux matrices OBD/langues/versions.
Rapports : JUnit/Allure + artefacts de logs de conteneurs (en cas de chutes).
Gate : « unité verte + intégration critique » est une condition de la merge ; e2e - sur 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 et événements

Contrats de service : OpenAPI/Protobuf sont versionnés ; tests de compatibilité (backward).

• Unité : mapping d'événements de domaine et invariants.
• Intégration : publication/abonnement chez un vrai courtier (Kafka), outbox/inbox sémantique, imitation exactly-once (au moins - idempotent).
• Tests de rétroaction/duplication/réorganisation (out-of-order).

12) Données et isolation dans l'intégration

Chaque test → un schéma/OBD unique (Testcontainers JDBC URL' ? TC _ TMPFS =/var/bou/postgresql/data : rw ').
Les fiches transactionnelles (begin→run→rollback) accélèrent le nettoyage.
Pour Redis/cache, le préfixe clé 'test : $ {RUN _ ID} :' et 'FLUSHDB' dans teardown.

13) Spécificités d'iGaming/Finance

Argent et limites : tests de propriété-base pour les invariants (solde ≥ 0, limites totales).
Réglementation : vérification du journal (l'audit-journal est écrit), événements immuables.
Paiements/PSP : tests d'intégration HMAC/mTLS, 'Retry-After', idempotence, dedup 'jti'.
Jeu responsable : tests des règles des seuils/couldowns ; « vchera→segodnya » sur fake clock.

14) Anti-modèles

« Unit », qui soulève la base de données/NTTR, est déjà une intégration (confondre les couches et ralentir le CI).
Haut coverage au détriment des déclarations vides (« couvertes mais non vérifiées »).
Mocks de la logique des services tiers où vous avez besoin d'un contrat (cassé lors de la mise à jour).
Les tests avec 'sleep (5)' au lieu des attentes de l'événement/condition.
Une base de données d'essai commune pour les essais parallèles → la course et la flûte.

15) Chèque-liste prod-prêt

• La pyramide est définie par :% des parts de la Unit/Integration/E2E et de l'objectif en fonction du temps de course.
• L'unité est isolée, rapide, couvre les valeurs limites et les invariants.
• L'intégration utilise un environnement hermétique (Testcontainers/Composite), sans status communs.
• Les tests contractuels (OpenAPI/Pact) sont vérifiés dans l'IC.
• Données de test - gérables : seed/rollback/préfixes, fake clock.
• Exécution parallèle, rapports JUnit/Allure, artefacts de logs de conteneurs.
• Métriques : duration, taux de flaky, score de mutation ; les alertes à la dégradation.
• Scripts de paiement/webhook : HMAC/mTLS, retraits, idempotence, dedup.
• Documentation de la stratégie et exemples de modèles de test.

16) TL; DR

Unité - maximum de logique, minimum d'environnement ; L'intégration est un minimum de mokov, un maximum de réalisme. Gardez la pyramide : l'unité rapide attrape 80 % des défauts, l'intégration confirme les ligaments et les contrats. Utilisez des conteneurs hermétiques, des tests contractuels, de l'horloge fake et de la parallèle. Mesurez non seulement le coverage, mais aussi le score de mutation et le taux de flaky. Vérifiez en particulier les chemins de paiement/webhook : signatures, retraits et idempotence.