Classpath d'Eclipse et classes d'exécution pour une exécution facile des cas de test junit

Question

J'ai un grand projet d'éclipse avec plusieurs classes junit. J'essaie de trouver un équilibre entre l'ajout de ressources d'exécution au classpath du projet eclipse et la nécessité de configurer des configurations de lancement mutliple junit. Je me rends compte que le chemin de classe de construction eclipse par défaut est hérité par toutes les configurations de test unitaires, mais certains de mes tests nécessitent des ressources d'exécution supplémentaires. Je pourrais ajouter ces ressources au classpath de construction, mais cela ralentit mon temps de construction global du projet (puisque il doit garder plus de fichiers synchronisés). Je n'aime pas l'idée d'inclure * ressources et jars sur le classpath runtime.

Les deux options que j'ai ces choses, les cas positifs et négatifs que je vois sont énumérés

1: Ajouter toutes les ressources d'exécution pour éclipser classpath. POS Je peux sélectionner un test unitaire et l'exécuter sans avoir à configurer le chemin de classe de test. POS

POS Des ressources supplémentaires sur le chemin de classe de construction signifie que l'éclipse ralentit.

NEG Plus difficile de s'assurer que chaque test utilise les bonnes ressources.

2: Configurer le classpath de chaque test unitaire

• POS Je sais exactement ce que les ressources sont utilisées par un test.
• POS Un plus petit chemin de classe de construction signifie une construction plus rapide et une exécution par éclipse.
• NEG Il est difficile de configurer plusieurs chemins de classes junit runtime séparés. Idéalement, je voudrais configurer une configuration d'exécution de base junit, qui prend le chemin de classe de construction eclipse par défaut, ajoute des jars et des ressources d'exécution supplémentaires. Cette configuration pourrait ensuite être réutilisée par les cas de test de junit spécifiques. Est-ce que quelque chose comme ça est possible?

  Regarder une configuration de lancement JUnit spécifique qui peut être exporté vers un fichier de projet part

  <?xml version="1.0" encoding="UTF-8" standalone="no"?> 
  <launchConfiguration type="org.eclipse.jdt.junit.launchconfig"> 
  <stringAttribute key="bad_container_name" value="/CR-3089_5_1_branch."/> 
  <listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS"> 
  <listEntry value="/CR-3089_5_1_branch/src/com/x/y/z/ParserJUnitTest.java"/> 
  </listAttribute> 
  <listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES"> 
  <listEntry value="1"/> 
  </listAttribute> 
  <stringAttribute key="org.eclipse.jdt.junit.CONTAINER" value=""/> 
  <booleanAttribute key="org.eclipse.jdt.junit.KEEPRUNNING_ATTR" value="false"/> 
  <stringAttribute key="org.eclipse.jdt.junit.TESTNAME" value=""/> 
  <stringAttribute key="org.eclipse.jdt.junit.TEST_KIND" value="org.eclipse.jdt.junit.loader.junit4"/> 
  <stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="com.x.y.z.ParserJUnitTest"/> 
  <stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="CR-3089_5_1_branch"/> 
  </launchConfiguration> 
  

  est-il possible d'étendre/réutiliser cette configuration, et paramétrer le « org.eclipse.jdt.launching.MAIN_TYPE ' valeur? Je suis conscient du lancement des communs et des solutions de fichiers manifestes jar pour configurer le classpath, mais ils semblent tous deux supposer qu'une ant build est exécutée avant que le test puisse s'exécuter. Je veux éviter toute dépendance d'éclipse sur l'appel d'une cible de fourmis lorsque refactoting code et l'exécution de tests.

  Fondamentalement - Quelle est la manière la plus simple de séparer et de maintenir les chemins de classes eclipse buildtime classpath et junit runtime?

Answer 1

La première solution pourrait consister à séparer complètement le projet de ses tests unitaires:

• un projet pour la construction en cours
• un projet pour les tests JUnit (ou plusieurs si différents types de classpath sont impliqués) : ce projet aura le premier projet dev dans ses dépendances, et n'aura pas à spécifier le classpath de ce développement.

Une façon plus propre (car il serait utilisé dans Eclipse, mais aussi à l'extérieur Eclipse) serait de transformer votre projet dans un maven un, through m2eclipse par exemple.
De cette façon, maven peut gérer les compositions de dépendances de plusieurs projets afin d'avoir le bon chemin de classe pour la tâche de test.