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

Question

J'ai un projet dont je suis bâtiment avec Maven qui utilise Hibernate (et au Printemps) pour récupérer des données à partir d'une base de données, etc.

Mes "tests" pour les DAOs dans mon projet d'étendre le Printemps de l' AbstractTransactionalDataSourceSpringContextTests , de sorte qu'une source de données peut être câblé dans ma classe en cours de test pour être en mesure d'exécuter la requête/Hibernate logique, d'extraction des données, etc.

Sur plusieurs autres projets, j'ai utilisé ces types de test, de concert 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 il permet d'éviter toute dépendance externe et "l'état" de la base de données avant de lancer les tests (qui sont enveloppés dans une transaction qui est restaurée) est bien définie.

Je suis curieux de savoir si la meilleure façon d'organiser ces tests, qui sont vraiment un lâche saveur de tests d'intégration avec Maven. Il se sent un peu sale à garder ces tests en src/test/java, mais de ce que j'ai lu il ne semble pas être une stratégie cohérente ou pratique pour l'organisation des tests d'intégration avec Maven.

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

Donc ma question est fondamentalement - qu'est-ce que les meilleures pratiques généralement acceptées sur la façon d'organiser cela avec Maven? Je vais avoir du mal à trouver toute sorte de cohérence de la réponse dans la documentation.

Ce que j'aimerais c'est:

• Séparer les tests unitaires à partir des tests d'intégration, de sorte que seules les tests unitaires sont exécutés au cours de l' test phase
• La capacité à se lier personnalisé démarrage/arrêt de la logique d' pre-integration-test et post-integration-test
• Avoir les rapports de l'intégration-tests fusionné/présenté avec l'unité de test Infaillible rapports

Answer 1

Une méthode très simple consiste à utiliser les catégories JUnit.

Vous pouvez ensuite facilement exécuter certains tests au cours de la phase de test et un autre au cours de la phase de test d'intégration.

Cela prend quelques minutes et ne nécessite que 3 étapes.

1. Définir une interface de marqueur
2. Annoter les classes que vous souhaitez diviser
3. Configurez les plugins Maven.

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

Answer 2

Il y a cette codehaus page avec quelques lignes directrices. J'ai trouvé le failsafe plugin un peu un hack, et il rend l'exécution des tests unitaires dans Eclipse diablement compliqué. - Je faire dans les grandes lignes ce que vous décrivez.

Définir les tests d'intégration dans src/itest/java Dans le pre-integration-test phase:

• Objectif clair/test-classes
• Utiliser le build-helper-maven-plugin'add-test-source pour objectif d'ajouter de la itest l'emplacement de la source
• Utiliser un Mojo pour supprimer src/test/java à partir de la configuration pour les tests unitaires ne sont pas compilés à nouveau (je n'aime pas vraiment ça, mais il est nécessaire de maintenir la séparation des tests unitaires et d'intégration).
• Utiliser le compiler-plugin compiler les tests d'intégration

Puis dans l'intégration-la phase de test, l'utilisation de la surefire-plugin pour exécuter les tests.

Enfin, lier tout ranger des objectifs pour l'après-intégration-phase de test (bien que normalement ils ne sont pas nécessaire car vous pouvez utiliser le test de permutation() pour mettre de l'ordre).

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

Mise à jour: je pense qu'il est intéressant de souligner que vous pouvez exécuter la Jetée de l'intérieur de vos tests d'intégration plutôt que d'utiliser une jetée de l'objectif. Cela vous donne beaucoup plus de contrôle sur les tests. Vous pouvez obtenir plus de détails à partir de cette réponse et les blogs référencés.

Answer 3

Ceci, http://javamoods.blogspot.com/search?q=unit+and+integration+maven , bon article de blog suggère trois options;

1) Module séparé pour les tests d'intégration

2) différents répertoires sources

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

Je n'ai pas encore essayé les trois, alors je ne peux pas donner un avis sur lequel je suis favorable.

Answer 4

Je préfère la deuxième option, Différents répertoires sources, mais j’ai trouvé assez ennuyeux de devoir terminer par les tests d’intégration ou l’exclusion des packages.

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

puis je remplace les deux variables dans des profils différents pour les tests d'intégration et 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>
.....
.....
.....