Comment écrire des tests d'intégration

Rappels

Qu'est ce qu'un test unitaire ?

Un test unitaire examine le comportement d'une unité distincte / identifiée de travail

• les tests unitaires doivent tester le code en isolation
• les tests doivent s'exécuter rapidement
• les tests unitaires doivent être faciles à écrire et à exécuter

Qu'est ce qu'un test d'intégration ?

Un test d'intégration traque les défauts dans les interfaces et les interactions avec d'autres composants

Un test d'intégration vérifie les interfaces entre les modules, les échanges de données.

Scénario typique :

Quand je veux vérifier que le lien entre les modules Facturation et Comptabilité 
Quand l'utilisateur créer une facture
Et la facture à un montant de 400€
Alors la facture est payée
Et le solde de la comptabilité a changé

• les tests d'intégration comportent une ou plusieurs dépendances partagées
• les dépendances partagées nécessitent d'être initialisées / détruites et possède un état.
• les tests d'intégration peuvent nécessiter le chargement de données plus ou moins complexes.

Les recommandations de terrain

• Suivre les recommandations de conception du code du chapitre Concevoir un code testable

• Remplacer les dépendances par des doubles de tests (base embarquées, stubs, etc) n'apportent qu'une sécurité limitée

• Cibler principalement les API publiques et autres interfaces.

• les base de données embarquées ne couvrent pas le périmètre complet des SGDB, aussi le test des requêtes SQL n'est pas assuré

• le chargement des données est possible avec DBUnit mais est fastidieux, il est plus simple d'utiliser un container, de le build avec un schéma SQL et l'utiliser dans un TestContainer.

• si l'API Rest de votre service est correctement écrite, les tests d'intégration peuvent remplacer efficacement de nombreux tests unitaires.

Les stratégies d'écriture de tests d'intégration

• Il y a trois approches pour les tests d'intégration
• L'Approche BigBang
• L'Approche Bottom-up
• L'Approche Up-Bottom

L'approche Big bang

Le test d'intégration connecte tous les modules d'un coup.

Le test vérifie si le système travaille comme attendu.

Avantages:

• Bonne approche pour de petits systèmes
• Les tests couvrent plus de code.

Désavantages:

• Il est difficile de détecter le module qui provoque le bug
• Les tests sont compliqués à initialiser et lents
• Incompatible avec une approche de prototypage.

L'approche Bottom-Up

Le test d'intégration vérifie les couches basses de l'application (les modules internes et remonte progressivement)

Avantages:

• Les modules les plus enfouis sont testés en premiers car ils sont les plus compliqués à déboguer.
• Compatible avec les prototypes

Désavantages:

• Le fonctionnement global de l'application n'est testé que très tardivement.
• Tester les couches basses est fastidieux sauf pour certains types d'architecture
• Nécessiter de développer des Stubs pour les blocs non développés

L'approche Up-Bottom

Le test d'intégration démarre par les API visibles des couches supérieures et procède ensuite par les modules intérieurs jusqu'à obtenir la qualité requise.

Avantages:

• Sur les applications de type RESTFul ou qui utilisent des frameworks comme Spring, Akka etc, il est facile d'identifier des modules techniques dans les couches supérieures (Contrôleurs, Services).
• Souvent, les tests n'iront pas jusqu'à vérifier les modules internes si la couverture est jugée suffisante.

Désavantages:

• Il est facile de confondre tests systèmes et tests d'intégration dans l'approche Bottom-Up.
• Cette approche n'est possible que si la couche présentation est bien séparée.