Tester les intégrations MuleSoft (Course #testing-integrations)

Programme chaque ligne est quelque chose que vous faites

6 modules · 18 sujets · dans l'ordre du cours

1. Module 1

   Structurer la pyramide de tests

   Objectif. Arbitrer ce qui se vérifie à chaque étage de la pyramide et livrer une matrice de tests priorisée par risque par API.

   • Cartographier niveaux unitaire/intégration/E2E sur un patrimoine API-led, cible : effort réparti 70/20/10
   • Pondérer les routes d'erreur de chaque flow par fréquence d'incidents pour ordonner les tests
   • Signaler les anti-patterns de pyramide inversée via ratios couverture/durée (suites > 5 min)
2. Module 2

   Gater les flows avec MUnit

   Objectif. Instrumenter les flows avec mocks de connecteurs et spies jusqu'à ≥ 80 % de couverture des routes d'erreur, preuves à l'appui dans le rapport de suite.

   • Écrire des suites MUnit avec mocks de connecteurs, spies sur les flows et assertions de payloads (cible : ≥ 80 %)
   • Couvrir chaque branche d'error handler, reconnexions comprises, avec connecteurs moqués et ports dynamiques
   • Paramétrer les tests MUnit par jeux d'entrées pour valider plusieurs mappings sans duplication
3. Module 3

   Casser le build sur régression

   Objectif. Brancher MUnit en CI et publier des preuves de couverture qui font échouer tout build sous le seuil convenu.

   • Exécuter MUnit via Maven dans le pipeline et publier le coverage par module (gate : échec sous 80 %)
   • Configurer des coverage gates et une quarantaine des tests instables (max 1 relance automatique par suite)
   • Versionner les suites près des specs RAML/OAS pour mettre à jour les tests de contrat dans la même PR
4. Module 4

   Tester par contrat, pas par espoir

   Objectif. Piloter des suites Postman et SoapUI depuis le mocking service et prouver la conformité à la spec publiée.

   • Générer des collections Postman depuis des specs OAS/RAML et les exécuter contre le mocking service
   • Vérifier codes de statut, headers et contrats d'erreur par endpoint, jusqu'aux schémas de payloads 4xx
   • Isoler les sandboxes dev/test par variables d'environnement et secrets pour une collection unique partout
5. Module 5

   Charger jusqu'à la rupture

   Objectif. Quantifier les plafonds de débit par profils ramp-and-soak et nommer le goulot principal de chaque tir de charge.

   • Scripter des profils de charge avec JMeter ou k6 : rampe 0→200 TPS puis soak de 30 minutes hors production
   • Lire latence p95/p99, taux d'erreur et pauses GC pour distinguer saturation et fuite mémoire
   • Imputer les goulots aux pools de connexions, au nombre de threads ou à un budget d'appel aval de 300 ms
6. Module 6

   Déterministe ou inutile

   Objectif. Éliminer l'instabilité par mocks des systèmes externes, fixtures maîtrisées et exécutions idempotentes et répétables.

   • Bouchonner les systèmes externes pour qu'aucun test n'atteigne un PSP, CRM ou mainframe réel
   • Injecter et purger les données de test à chaque run (fixtures, scripts de teardown) pour des exécutions répétables
   • Isoler en quarantaine les tests instables derrière un budget de relances (≤ 2) et suivre leur résorption vers zéro

Références & documentation officielle chaque affirmation ci-dessus a une source

Module 1

• Présentation de MUnitDoc MuleSoft

Module 2

• Processeur d'événement Mock WhenDoc MuleSoft
• Suites de tests MUnit paramétréesDoc MuleSoft
• Processeur d'événement SpyDoc MuleSoft

Module 3

• Configuration Maven pour la couvertureDoc MuleSoft

Module 4

• Simuler des appels d'API avec le service de mockDoc MuleSoft

Module 5

• Validation des tests de performanceDoc MuleSoft

Module 6

• Ports dynamiquesDoc MuleSoft

Dans la filière Assurance qualité