Tests d'intégration : automatisation et reporting

Spécifie les limites des outils, l'exécution en CI, le triage des échecs, le reporting, la maintenance et les seuils de qualité pour les tests d'intégration. Il fixe les limites d'adoption et les preuves d'échec observables tout en gardant les limites spécifiques à l'environnement configurables.

Statut du package : contexte de référence prêt pour revue humaine. Le contrat et les scénarios de test sont complets, mais aucune affirmation n'est faite qu'une implémentation adoptante les ait validés.

Décision

Pour les tests d'intégration, adopter un plan de test versionné basé sur les risques avec des fixtures reproductibles et des seuils propriétaires. Faire fonctionner la capacité avec des signaux nommés, une capacité limitée, des alertes propriétaires, un runbook de diagnostic et des preuves de récupération testées. Ce package est un contrat de référence : l'équipe adoptante doit choisir les limites numériques, les fournisseurs, les juridictions et les propriétaires opérationnels à partir des preuves dans son propre environnement.

Portée

• Les acteurs, entrées, sorties, états, versions de politique ou de schéma, et résultats visibles de l'extérieur décrits par ce bloc opérationnel des tests d'intégration.
• Interfaces principales et alternatives, travaux en arrière-plan, caches, intégrations, chemins de support, et preuves pouvant exercer la même limite.
• Configuration spécifique à l'adoption, déploiement, récupération et responsabilités de vérification nécessaires pour appliquer la référence en toute sécurité.

Hors de ce bloc

• Choisir un fournisseur universel, un framework, une juridiction, un seuil numérique, une période de rétention ou un objectif de niveau de service pour chaque adoptant.
• Affirmer que les scénarios packagés ont été exécutés contre une implémentation en aval ou que cette référence accorde une certification légale, de sécurité ou d'accessibilité.

Contrat

• Tracer chaque test critique à un comportement, une limite, un incident ou un risque et affirmer des résultats visibles de l'extérieur ou des preuves durables.
• Contrôler l'horloge, l'aléatoire, l'identité, le réseau et les dépendances de données pour que les réexécutions distinguent les défauts produit de l'instabilité des fixtures.
• Garder les données sensibles en production et les identifiants hors des fixtures ; générer des cas synthétiques représentatifs de limites et d'abus.
• Définir les critères de retry, quarantaine, propriété, expiration et suppression pour les tests instables ; les retries ne peuvent pas transformer un échec en succès silencieux.
• Définir les états normal, dégradé, épuisé et indisponible avec des métriques décisionnelles et des actions explicites de l'opérateur.
• Préserver l'identité du travail accepté lors du basculement, de la relecture, du rollback et de la réparation pour que la récupération ne duplique pas ou ne perde pas silencieusement les effets.
• Exercer de vraies limites et schémas propriétaires avec une authentification, une autorisation, des données, un timing, des duplications, des échecs et des comportements de récupération représentatifs plutôt que de dupliquer les internes unitaires.
• Isoler les effets externes via des dépendances contrôlées ou des sandboxes, créer des fixtures déterministes, les nettoyer par propriété et préserver les preuves de corrélation pour les échecs.

Guide de mise en œuvre

• Pratiquer le runbook dans un environnement représentatif et enregistrer le temps de récupération, la limite de perte de données et les hypothèses non résolues.
• Modéliser les entrées, sorties, acteurs, états, invariants, effets secondaires et preuves des tests d'intégration avant de sélectionner les détails du framework ou du fournisseur.
• Stocker la version applicable du contrat ou de la politique des tests d'intégration avec l'état matériel pour que les migrations, relectures et décisions de support restent attribuables.
• Introduire le chemin derrière un déploiement contrôlé, comparer les résultats attendus et observés, et garder une route de récupération testée jusqu'à ce que les preuves d'adoption soient complètes.

Gestion des échecs et protections

• Un environnement de test cassé rapporte un résultat d'infrastructure distinct d'un échec produit et ne peut satisfaire un seuil de publication requis.
• Un état invalide ou contradictoire des tests d'intégration est rejeté ou mis en quarantaine ; l'implémentation ne devine jamais une valeur qui élargit l'autorité ou duplique un effet.
• Les retries sont limités et utilisent une identité durable ; après épuisement, le travail atteint un état terminal inspectable avec un propriétaire responsable.

Vérification et opérations

• Injecter saturation, panne de dépendance, configuration obsolète et perte de télémétrie et confirmer le comportement dégradé déclaré.
• Surveiller le succès, le refus, l'échec de validation, l'échec de dépendance, l'épuisement des retries et la récupération des tests d'intégration par version de contrat sans dimensions sensibles de charge utile.
• Réexécuter les fixtures positives et négatives appariées après des changements de politique, schéma, dépendance, migration ou limite et préserver les preuves résultantes.

Hypothèses d'adoption

• Les noms et valeurs dans l'exemple sont une fixture concrète, pas des valeurs par défaut universelles ; les adoptants les remplacent par des preuves documentées et une propriété.
• Le système adoptant peut fournir une identité authentifiée, des versions durables d'opération ou d'enregistrement, une télémétrie limitée et un chemin contrôlé pour le changement.

Les exemples à l'apparence exécutable dans ce package sont des fixtures et des contrats d'acceptation. Exécutez le validateur de collection pour vérifier la structure et les métadonnées, puis traduisez et exécutez les scénarios dans le dépôt cible avant d'enregistrer les preuves d'implémentation.