• Vous êtes ici :  
  • Accueil
  • Les Tests d’intégration avec Junit
Conseils, services, ingénierie en informatique. Mise en place de solutions technologiques, et support, pour les entreprises.

Note utilisateur: 4 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles inactives
 
Détails

Les Tests d’intégration

 

Junit logo

 

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 :

  1. -tests unitaires (tester une classe en l’isolant avec des mocks)
  2. -tests d’intégration (tester un sous ensemble de classes, techniquement autonome)
  3. -tests systèmes
  4. -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.

  1. 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 :

  1. -une connexion à une base de données
  2. -un web-service
  3. -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?