Le projet que je travaille est composé de plusieurs modules, construit avec Maven. Le code de test dans certains modules a des dépendances sur le code de test d'autres modules. Ces dépendances sont déclarées ci-dessous.
Dans le module de dépendance: p> dans le module qui a la dépendance du module précédent: p> [WARNING] JAR will be empty - no content was marked for inclusion!
3 Réponses :
Je crois fermement que les tests ne doivent faire partie d'un module. Vous ne devriez pas dépendre des tests d'autres modules. Il est très difficile de prédire ce qui se passe si vous mettez à jour les tests pour se comporter différemment.
Si vous devez partager des données de test communes ou des classes de test communes, il est préférable de créer un module séparé avec cette source de test partagée. Puis laissez tous les tests avoir une dépendance sur le pot-bocal partagé avec le test de portée. Assurez-vous que vous ne dépendez que du sur le niveau supérieur et tous les tests seront exécutés . common-test-util avec <étendue> test , puis vous pourrez appeler
Je suis respectueusement mal. Mocks, tester les doubles, les talons, les pilotes et autres formulaires de test sont souvent utilisés entre les modules, mais ne doivent pas être inclus dans le code d'exécution. Construire un pot-bocal commun avec votre jar de code commun ordinaire fonctionne très bien. Bien que je conviens bien sûr que les tests spécifiques aux internes du pot commun ne devraient pas être utilisés dans d'autres modules. Vous pouvez séparer ces deux catégories de code mais cela ne vaut souvent pas l'effort. Si vous avez un cadre de test important, faites-en un projet séparé bien sûr.
@AutomatedMike c'est plus ou moins ce que je dis. Mettez tout ce genre de choses dans un pot et utilisez dans les différents tests d'autres modules. Mais n'essayez pas de le fourrer dans src / test / java . Il suffit de mettre vos tests réels là-bas.
@MABA - ModuleB est des tests d'intégration, j'ai une DTO dans des modules, j'ai besoin de placer un luminaire quelque part que je peux utiliser à la fois dans les modules et le module B. Quelle est votre suggestion dans ce cas?
Votre problème est bas à la résolution de dépendance dans les bâtiments multi-module. Il n'est pas spécifiquement lié au code de test.
J'ai exactement cette configuration. Un module commun contient un code d'exécution avec le code de test partagé (test double et moqueurs, etc.). Le code de test est utilisé par des tests dans d'autres modules. Cela fonctionne très bien pour nous.
"Compiler MVN" ne compile que le code d'exécution.
Exécution d'un "Compilation de test MVN", "MVN Test" ou "Package MVN" au niveau parent (construction du réacteur) Tout fonctionne parfaitement. Le réacteur peut tout trier.
Si vous exécutez une construction au niveau du module, toutes les dépassades de ce module doivent être dans un repo. Cela signifie que vous devez avoir couru de manière courante une "installation MVN" pour chacun des modules dépendants. Cette règle s'applique également aux dépendances ordinaires et aux tests.
Si vous espérez que cela suivrait que le parent et le parent jusqu'aux autres modules, je dois vous décevoir. La liaison parent n'est utilisée que pour hériter des paramètres communs dans la POM et non pour la résolution de dépendance.
Personnellement, je fais presque toujours une construction de réacteurs complète du parent. Je ne fais qu'un module individuel construit si j'ai déjà exécuté une installation MVN au niveau des parents et je sais que les autres modules n'ont pas changé.
espère que cela aide.
Je pense que cette configuration de plugin fonctionne pour vous.
Il suffit de remplacer le skip à False dans la préparation des ressources et la compilation. P>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>default-testResources</id>
<configuration>
<skip>false</skip>
</configuration>
<phase>process-test-resources</phase>
<goals>
<goal>testResources</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-testCompile</id>
<configuration>
<skip>false</skip>
</configuration>
<phase>test-compile</phase>
<goals>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<configuration>
<skip>false</skip>
</configuration>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
Eu un problème similaire avec certains plugins. Intéressé.
J'ai eu un problème similaire hier, puis j'ai réalisé que j'avais l'option Maven.Skip.Test à True. Pourrait-il être quelque chose de similaire dans votre cas?
Votre déclaration test-jar semble un peu étrange, pourriez-vous nous montrer l'en-tête du POM de ce module associé?
Pourquoi ne veux-tu pas exécuter
mvn installer ? Jetez un coup d'oeil à la Référence Maven LifeCycle . Vous devriez être capable d'utiliser la commandeMVN .@Farid Qu'est-ce qui est étrange à ce sujet? Regarde bien pour moi.
@Duncan: En supposant que la dépendance est un pot, son POM serait normalement déclaré comme JAR , et donc lors de la référence à cet artefact, vous le spécifiez à l'aide de JAR
@MABA Oui, je devrais pouvoir exécuter la phase package avec succès, mais c'est juste que je veux parfois courir uniquement à la Compiler ou test phase.
@Farid C'est parce qu'il a suivi ce guide de Maven: Maven.apache .org / guides / mini / guide-attaché-test.html
@Farid Test-Jar semble être un type valide, selon la page Maven .apache.org / pom.html
Je vois, merci pour le lien. Je n'ai jamais utilisé ce type de déclaration sur mes projets. J'utilise toujours l'approche de type traditionnelle de type sur mon projet Multi Module, même lorsqu'il existe des dépendances croisées de module pour des tests d'unités.
Voir aussi Stackoverflow.com/a/2532486/1072626 qui semble être similaire à la réponse de @ Rainyoung ci-dessous.