Les Tests d’intégration
Après avoir pris en compte les tests unitaires, il faut maintenant prendre en compte les tests d’intégration.
Rappels :
La phase de validation comporte plusieurs étapes de tests :
- -tests unitaires (tester une classe en l’isolant avec des mocks)
- -tests d’intégration (tester un sous ensemble de classes, techniquement autonome)
- -tests systèmes
- -tests fonctionnels
Pour les tests d’intégration, si je fais un composant, je veux tester un chemin dans mon tir d’intégration. J’ai plusieurs classes, je veux les tester dans son ensemble.
Exemple : valider un chemin dans le tiers intégration pour sauvegarder des données.
2 pistes :
Automatisation des tests unitaires avec MAVEN
Il faut automatiser ces tests après les tests unitaires à ajouter un plugin MAVEN dédié à la phase d’intégration.
Choix d’un outil de test d’intégration, JUnit
Configurer ce plugin : choisir un outil de test d’intégration.
On peut utiliser SPRING et son module SPRING Integration.
Il y a aussi Apache Camel, avec camel-test
JUnit a introduit de nouvelles annotations : @categories, @Rule , plus l’emploi d’interfaces. ExternalResoure.
On sait déjà faire des tests unitaire avec JUnit, on va pouvoir s’en resservir.
Pour construire un test d’intégration avec JUnit, il faut suivre quelques étapes.
Tout d’abord, définir un marqueur : en java, c’est une interface.
- Marqueur
Je définis un package, « integration » et je crée une interface, je l’appelle comme je veux.
|
package integration; publicinterface IntegrationTest { // Des métriques de codage à implémenter
} |
Une question? Posez-la ici
2) Classe de test d’intégration
Je définis une classe de test d’intégration :
|
package integration; @Category(IntegrationTest.class) publicclass IntegrationRationnelTest { //Définir un automate qui enchaine CascareRationnel et RationnelCalculette
} |
But du test : valider l’enchainement des tests d’un ensemble de classes
3) Configurer le plugin MAVEN pour le test unitaire pour exclure les tests d’intégration
Car pour le plugin test-unitaire, toute classe ce qui se trouve dans le source folder de Test et suffixée src/test/java est un test unitaire potentiel. On considère que l’on a déjà ce source folder, créé lors d’un nouveau projet Maven.
Dans le pom.xml
|
<plugin> <groupID>org.apache.maven.plugin</groupID> <artefactID>maven.surfire.plugin</artefactID> <version>2.19.1</version> <configuration> <includes> <include> **/*.class </include> <includes> <excludedGroups> Integration.IntegrationTests <excludedGroups> </configuration> </plugin> |
J’inclue toutes les classes *.class mais il y en a trop, je vais en exclure
Maintenant que la configuration est faite, il faut ajouter le plugin pour les tests d’intégration.
REMARQUE : Ici, attention, le point de référence du plugin c’est java, ce n’est pas le projet.
Une question? Posez-la ici
4) Configurer le projet afin de prendre en compte le nouveau plugin MAVEN
J’ajoute au pom.xml :
|
<plugin> <groupID>org.apache.maven.plugin</groupID> <artefactID>maven.failsafe.plugin</artefactID> <version>2.12</version> <configuration> <groups> Integration.IntegrationTests </groups> </configuration> <executions> <execution> <goals> <goal> </goal> Integration-test </goals> <configuration> <includes> <include> **/*.class </include> </includes> </configuration> </execution> </executions> |
Je recopie celle que j’avais exclue auparavant
Lors de l’execution : mvn test
D’abord sont effectués les tests unitaires
Puis sont effectuées les tests d’intégration annotés intefration.integrationtests
Remarque : comment bien rédiger une classe de test d’intégration ?
|
ackage integration; @Category(IntegrationTest.class) publicclass IntegrationRationnelTest { //Définir un automate qui enchaine CascareRationnel et RationnelCalculette
@Rule privatefinal RationnelResource resource = new RationnelResorce("cascade.xml");
} |
L’annotation @Rule permet de définir des invariants, autrement dit des propriétés qui doivent toujours être satisfaites.
But : tester l’exisence d’une ressource afin d’assurer qu’elle est toujours présente :
- -une connexion à une base de données
- -un web-service
- -un fichier dans un répertoire convenu
J’avais mon xml dans le répertoire : src/test/resource/cascade.xml
Lors de l’execution du test d’intégration, touts les règles (invariants) sont parcourues avant (méthode before) et après (méthode after) chaque méthode de test.
Il est possible d’observer que la resource d’entrée est accessible, qu’une resource en sortie est fournie.
Voir exemples de Junit.
On peut tester par exemple une url vers une image sur un repository GIT. Est-ce que l’image existe ? Est-ce que j’ai un timeout ? par exemple si timetout>5000, test fail.
On teste avant l’accès à l’image
On peut aussi tester qu’un un web-service récupère l’heure par exemple. Il faut tester, car si je n’ai pas une base de temps, d’heure je ne peux pas synchroniser à intervalles réguliers par exemple…Des questions?