Une application est souvent composée de plusieurs composants (modules, couches, services externes). Tandis que les tests unitaires se concentrent sur les exigences propres à un composant, les tests d’intégrations vérifient un composant avec ses autres composants. Ils ont pour objectif de tester le code d’une application dans son ensemble. Par exemple, une API créant un nouvel utilisateur.
Les tests d’intégrations se lancent après les tests unitaires parce qu’ils sont moins rapides. Il existe plusieurs méthodes pour créer des tests d’intégrations. Les plus connus sont le big-bang, top-down, bottom-up et sandwich.
Soudainement, le big-bang teste l’application avec tous ses composants. Il est généralement effectué pour gagner du temps, lorsque toute l’application (les composants) a été développée. À partir d’un système complet, on peut tester n’importe quelle partie de code. Dans une architecture trois tiers, par exemple, on pourrait ajouter un test sur la couche présentation qui appellera les autres couches, simulant le traitement d’une requête client.
Le top-down teste les modules les plus hauts et intègre les modules de plus en plus bas pour localiser les erreurs. C’est une approche incrémentale. Il utilise des bouchons (stub en anglais) pour isoler les modules inférieurs. Un bouchon remplace une fonctionnalité par un résultat afin de contourner son exécution. Exemple dans une architecture trois tiers : présentation A, traitement B et persistance C. La première étape serait de tester A en mettant des bouchons sur B, la deuxième étape de tester A avec des bouchons sur C, puis la troisième étape de tester A sans bouchon. Les modules seront intégrés dans cet ordre : A, A+B, A+B+C.
Également incrémental, le bottom-up teste d’abord les modules en partant du bas et remonte vers les modules supérieurs. Il se sert de pilote (driver ou mock en anglais) pour tester les différents modules. Un pilote appelle des objets (API, service, repository), simulant des scénarios. Par exemple, on appellera la fonction qui enregistre en base de données un nouvel utilisateur, comme si le composant supérieur l’avait demandé. Pour reprendre l’exemple précédent de l’architecture trois tiers : la première étape serait de tester C grâce à un driver comme si B l’appelait, la deuxième étape de tester B grâce à un driver qui simule A, et la troisième étape de tester A avec tous les modules. Les modules seront intégrés dans cet ordre : C, C+B, C+B+A.
Le sandwich combine le top-down et bottom-up. Il permet de tester en parallèle les modules en partant du haut, et les modules en partant du bas. Première étape : A (A avec bouchon B), et C (C avec driver B). Deuxième étape : A+B (A avec bouchon C), et C+B (B avec driver A). Troisième étape : A+B+C.
Il est intéressant de développer une application en commençant par les modules du haut ou du bas pour tester son intégration en même temps. La méthode big-bang n’est pas adaptée avec le développement en parallèle, sinon il faudrait créer des bouchons et des drivers sur tous les modules. Bien qu’il ne localise pas bien les erreurs, le big-bang est privilégié pour tester rapidement l’intégration d’une petite application.
