Meilleures pratiques pour les tests d'intégration avec Maven?

j'ai un projet que je construis avec Maven qui utilise L'hibernation (et le ressort) pour extraire des données d'une base de données, etc.

mes " tests "pour les OAD dans mon projet étendent le AbstractTransactionalDataSourceSpringContextTests de Spring de sorte qu'une source de données puisse être connectée dans ma classe sous test pour être capable d'exécuter réellement la logique de requête/hibernation, de récupérer des données, etc.

sur plusieurs autres projets j'ai utilisé ces types de test en conjonction avec une base de données HSQL (soit en mémoire ou en pointe sur un fichier) pour tester la réelle interrogation de bases de données logique sans compter sur une base de données externe. Cela fonctionne très bien, car cela évite toute dépendance externe et l ' "état" de la base de données avant d'exécuter les tests (dont chacun est enveloppé dans une transaction qui est retranscrite) est bien défini.

je suis curieux cependant sur la meilleure façon d'organiser ces tests, qui sont vraiment une saveur lâche de tests d'intégration, avec Maven. Il se sent un un peu sale pour garder ces tests dans src/test/java , mais d'après ce que j'ai lu, il ne semble pas y avoir de stratégie ou de pratique cohérente pour organiser des tests d'intégration avec Maven.

D'après ce que j'ai lu jusqu'à présent, il semble que je puisse utiliser le plugin Failsafe (ou une deuxième instance de Surefire) et le lier à la phase integration-test , et que je puisse également lier Démarrage personnalisé ou arrêt logique (comme pour démarrer/arrêter l'instance HSQL) pour pre-integration-test ou post-integration-test . Mais, est-ce vraiment la meilleure méthode?

donc ma question est essentiellement - Quelle est la meilleure pratique généralement acceptée sur l'organisation de ceci avec Maven? J'ai du mal à trouver une réponse cohérente dans la documentation.

ce que j'aimerais c'est:

  • séparer les essais unitaires des essais d'intégration, de sorte que seuls les essais unitaires sont effectués pendant la test phase
  • la possibilité de lier la logique de démarrage/arrêt personnalisé à pre-integration-test et post-integration-test
  • faire fusionner les rapports des essais d'intégration / présentés avec les rapports des essais unitaires
67
demandé sur Rich Seller 2009-08-04 21:00:21

4 réponses

il y a ce codehaus page avec quelques lignes directrices. J'ai trouvé le plugin failsafe un peu piraté, et il rend l'exécution des tests de l'unité dans Eclipse terriblement compliquée. Je fais largement ce que vous décrivez.

définir les tests d'intégration dans src/itest / java Dans la phase de pré-intégration-test:

  • objectif Clair/test-classes
  • utilisez le build-helper-maven-plugin s 'ajouter-test-source pour objectif d'ajouter de la itest l'emplacement de la source
  • utilisez un Mojo personnalisé pour supprimer src/test / java de la configuration afin que les tests de l'unité ne soient pas compilés à nouveau (je n'aime pas vraiment cela, mais c'est nécessaire pour maintenir la séparation des tests de l'unité et de l'intégration).
  • utiliser le compilateur-plugin pour compiler les tests d'intégration

puis dans la phase d'intégration-test, utilisez le surefire-plugin pour exécuter le test.

enfin, liez tous les objectifs de rangement à la phase post-intégration-test (bien que normalement ils ne sont pas nécessaires car vous pouvez utiliser le test teardown () pour ranger).

Je n'ai pas encore trouvé un moyen de fusionner les résultats des tests lorsque la phase de rapport a passé, mais je tendance à considérer les tests d'intégration comme un bonus supplémentaire, de sorte que tant qu'ils passent le rapport n'est pas si important.

mise à jour: je pense qu'il vaut la peine de souligner que vous pouvez exécuter Jetty de l'intérieur de vos tests d'intégration plutôt que d'utiliser un objectif de jetty. Cela vous donne un contrôle beaucoup plus fin sur les tests. Vous pouvez obtenir plus de détails à partir de cette réponse et les blogs référencés.

21
répondu Rich Seller 2017-05-23 12:34:50

une façon très simple de faire ceci est d'utiliser les catégories JUnit.

vous pouvez alors facilement exécuter certains tests pendant la phase de test et un autre pendant la phase d'intégration-test.

il prend des minutes et ne nécessite que 3 étapes.

  1. Définir une interface marqueur
  2. annoter les classes que vous souhaitez diviser
  3. configurer les plugins Maven.

Un exemple complet est donné ici. https://stackoverflow.com/a/10381662/1365383

25
répondu John Dobie 2017-05-23 10:31:02

ce bon billet de blog suggère trois options;

1) module séparé pour les essais d'intégration

2) répertoires de sources différents

3) différents modèles de nom de fichier

je suis encore à essayer les trois, donc je ne peux pas offrir une opinion sur laquelle je suis favorable.

7
répondu Mike 2016-04-27 05:59:39

je préfère la deuxième option, différents répertoires sources ,mais j'ai trouvé assez ennuyeux de finir avec elle les tests d'intégration ou d'exclusion des paquets.

Pour éviter cela, j'ai fini avec cette config: 

<properties>
    <testSource>src/test/java</testSource>
    <testSourceResource>src/test/resources</testSourceResource>
</properties>
<build>
    <testSourceDirectory>${testSource}</testSourceDirectory>
    <testResources>
            <testResource>
            <directory>${testSourceResource}</directory>
            </testResource>
        </testResources>
.....
.....

et puis j'annule les deux variables dans des profils différents pour l'intégration et le test d'acceptation: 

<profiles>
  <profile>
   <id>acceptance-tests</id>
   <properties>
    <testSource>src/acceptance-test/java</testSource>
    <testSourceResource>src/acceptance-test/resources</testSourceResource>
   </properties>
  </profile>
 <profile>
   <id>integration-tests</id>
    <properties>
    <testSource>src/integration-test/java</testSource>
    <testSourceResource>src/integration-test/resources</testSourceResource>
    </properties>
  </profile>
.....
.....
.....
1
répondu Pablo Gutierrez 2013-09-06 10:15:35