Dans le contexte du développement, le terme intégration signifie « l’incorporation (de nouveaux éléments) à un système ». Comme l’intégration d’un module avec un autre, d’un composant avec un autre, d’un système avec un autre ou l’intégration continue des features dans un système et ainsi de suite.
D’après cette compréhension de l’intégration, un test d’intégration consiste à vérifier le comportement de deux modules/composants/systèmes une fois intégrés ensemble. Autrement dit, un test d’intégration se concentre sur l’interfaçage et les interactions entre les composants/modules/systèmes.
A quoi servent les tests d’intégration ?
Les tests d’intégration peuvent être mis en place pour plusieurs raisons par exemple :
- Vérifier si les logiques implémentées par plusieurs développeurs différents fonctionnent correctement ensemble.
- Vérifier que la structure de donnée fonctionne sur la chaine de composants entière.
- Vérifier que l’interaction entre les modules est OK
- Interaction entre UI et API et base de données = OKInteraction entre UI et UI = OKInteraction entre base de données et base de données = OK
- Interaction entre API et API = OK
- Beaucoup de changements peuvent causer des erreurs que les tests unitaires ne vont pas couvrir ou ne couvrent pas encore.
Les challenges à devoir gérer pour assurer des tests d’intégration effectifs :
- La disponibilité d’un environnement de test avec les composants intégrés (sandbox).
- Complexité de la gestion des environnements et des bases de données (quelles données prendre ? iso prod ? etc).
- Intégration d’un module GenZ avec un système legacy.
- Intégration de deux modules développés par deux entités différentes, surtout si ça implique des questions de sécurité propre à chaque entité et si un changement dans un module impacte l’autre module.
Il existe plusieurs approches de test d’intégration adoptables :
L’approche Big Bang :
Comme le nom l’indique, elle consiste à attendre que tous les composants/modules soient disponibles et intégrés pour tout testé d’un coup. Elle peut être intéressante dans le cadre des petits systèmes mais elle a plusieurs limites :
- Il faut attendre d’avoir tous les modules disponibles avant de tester ce qui coûte beaucoup de temps.
- Difficulté d’associer un bug à un module à difficile de trouver facilement la root cause.
- Tous les modules doivent être développés et disponibles.
L’approche incrémentale Bottom-up :
Elle peut s’appliquer quand le développement se fait de façon incrémentale des composants en partant du composant le plus bas du système et graduellement intégré les composants au-dessus.
C’est-à-dire quand le module enfant est développé avant le module parent. Un module enfant est celui qui est appelé par un module parent, et un module parent est un module qui appelle le module enfant. Le comportement du module parent dépend du output de la fonction du module enfant.
Par exemple j’ai une api de connexion en module enfant, appelée par une UI de connexion qui représente le module parent.
Lorsque l’on parle de tester l’API, il s’agira de réaliser un test unitaire. Pour tester l’intégration entre les deux modules je vais avoir besoin soit d’attendre que le module UI soit développé soit le faire à travers un simulator appelé DRIVER. Un driver permet de simuler un module parent qui appelle un module enfant et dépend de celui-ci. Je vais donc simuler l’affichage des résultats de connexion sur l’UI pour savoir si l’intégration est bonne. Une fois que le module UI est développé je vais refaire mes tests d’intégration sur le vrai module.
L’avantage de cette approche c’est qu’elle facilite la détection et correction d’un bug mais l’utilisation d’un DRIVER n’est pas aussi fiable que de tester sur le vrai module.
L’approche incrémentale Top- Down :
C’est exactement le même principe que celui du Bottom up mais dans le cas où le développement se fait dans le sens inverse. C’est-à-dire que le module parent est développé avant le module enfant.
Dans notre exemple on commence par développer l’interface de connexion sans l’API et pour tester l’intégration on va également utiliser un simulateur de l’API que nous allons appeler dans ce cas un STUB. Un stub permet de simuler un module enfant appelé par un module parent.
Tout comme l’approche Bottom-Up, cette méthode est efficace pour trouver facilement le module introduisant le bug mais la création des stubs est aussi complexe et chronophage que le développement du module lui-même.
L’approche incrémentale Sandwich
Celle-ci est un mix entre Bottom-Up et Top-Down. Lorsque des modules parents et enfants sont développés en parallèle et on teste l’intégration à chaque niveau. Dans cette approche nous pouvons faire appel à des DRIVERS ou des STUBS en fonction du besoin pour simuler les modules pas encore disponibles.
Conclusion
Les tests d’intégration ont pour objectif de vérifier la cohésion entre les éléments de mon système.
Afin de pouvoir commencer mes tests d’intégration je dois d’abord comprendre l’architecture de mon application. Il est également primordial d’identifier l’ensemble des modules de celle-ci et de comprendre le rôle et ce que fait chaque module. Il est extrêmement important de savoir comment les données se baladent d’un module à un autre. La détermination des points d’entrées et de sorties de chaque module est aussi un prérequis.
Une fois ces éléments sont identifiés, je peux commencer à rédiger mes conditions de tests et faire la conception de mes tests pour couvrir chaque condition.
Il faut savoir que pour démarrer des tests d’intégration il existe une liste de critères d’entrée indispensables à devoir préparer. Dans cette liste nous trouvons :
- Le plan de test d’intégration approuvé techniquement et fonctionnellement
- Les cas de tests rédigés
- La stratégie de données et les données de tests créées (si cela n’est pas automatisé)
- Il faut absolument que les tests unitaires soient déjà exécutés et validés pour les composants en question
- Tous les bugs critiques ou majeurs provenant des tests unitaires sont fixés
- Enfin et surtout, l’environnement des tests d’intégration qui est opérationnel.
En ce qui concerne les critères de sortie qui peuvent faire partie des critères d’entrée des tests système, nous pouvons lister :
- L’ensemble des tests d’intégration exécuté.
- Pas de bug critique ou bloquant ouvert.
- Le rapport de test est disponible.
La théorie c’est bien mais la pratique ?
Si tu veux un peu de pratique je te propose l’exercice suivant, tu peux m’envoyer tes réponses via LinkedIn et je me ferais plaisir de les lire pour te faire un retour et te partager ma correction:
Prenons l’exemple de LinkedIn et considérons que les modules suivants sont des composants indépendants qui communiquent entre eux :
- Module de login
- Module de page d’accueil
- Module de page de profil
- Module de page de réseau (maintenant onglet Développer)
- Module de page de relations
- Module de page de notification
- Module de messagerie
- Le nouveau module de réseau (onglet Reprendre contact)
Je t’invite à rédiger un ou plusieurs tests pour vérifier l’intégration entre :
- Le module de login et le module home page
- Le module de home page et le module de la page de profil
- Le module de la page réseau (onglet développer) et le module de la page relations
- Le module de la page réseau (onglet Reprendre contact) et le module de la messagerie
- Le module de la page de notification et le module de la home page
À propos de l’auteur: Mohamed Hamza
Fondateur de Jawda (Jawda means quality), Co-Auteur de la conférence QA for all et ambassadeur de ce mindset.
Grand passionné de qualité, ses expériences entre Consultant QA, Senior QA Automation Engineer et Formateur QA lui ont permis de développer des fortes compétences dans ce domaine.
