Dans cet article, je vais illustrer l’infrastructure des tests d’intégration que j’ai utilisée pour le projet jena-nosql sur le compte GitHub de SpazioCodice.
Le cœur du projet n’est pas associé à un stockage spécifique, donc un ensemble de tests d’intégration qui s’exécutent contre une instance (mini) de stockage cible peu connu est nécessaire pour garantir la correction fonctionnelle de chaque liaison.
Dans le projet, vous pouvez voir un module (Maven) dédié aux tests d’intégration : le jena-nosql-integration-tests. Il est configuré avec le plugin Maven Failsafe pour exécuter les tests, pendant la phase integration-test, contre une instance en cours d’exécution du stockage cible.
Et voici la beauté du système, car le stockage cible n’est pas prédéfini mais dépend du module de liaison d’exécution qui a été choisi. Ainsi, le même ensemble de tests d’intégration peut être exécuté contre Cassandra, HBase, Accumulo, ou un autre stockage.
Comment pouvons-nous maintenir le même ensemble de tests et en même temps démarrer une instance de test d’un stockage ou d’un autre ? Les profils Maven sont la réponse (du moins pour moi) : dans le fichier pom.xml des jena-nosql-integration-tests, j’ai défini un profil pour chaque stockage (au moment de l’écriture, il y a seulement un profil 😉 ).
Par exemple, le profil cassandra-2x déclare l’utilisation du Cassandra Maven Plugin qui :
- Démarre une instance embarquée de Cassandra avant tous les tests d’intégration.
- Arrête cette instance après le dernier test d’intégration.
Ainsi, au final, si vous voulez exécuter la suite de tests d’intégration contre Cassandra, il vous suffit de vous rendre dans le répertoire du projet jena-nosql (là où se trouve le fichier pom.xml de niveau supérieur) et d’exécuter Maven comme suit :
> mvn clean install -P cassandra-2x
Vous n’avez pas besoin de définir des permissions ou des configurations, car l’instance embarquée “vivra” dans le dossier de construction cible.
