2010-12-07 18 views
7

J'ai un test qui compare un gros blob de XML attendu avec le XML réel reçu. Si le XML est significativement différent, le XML réel est écrit sur le disque pour analyse et le test échoue.Est-il possible pour e test JUnit de dire si elle fonctionne dans Eclipse (plutôt que ant) ​​

Je préférerais utiliser assertEquals pour pouvoir comparer plus facilement le XML dans Eclipse - mais cela pourrait conduire à de très gros journaux JUnit et CruiseControl.

Y a-t-il un moyen de modifier un comportement de test JUnit selon qu'il s'exécute via Eclipse ou via Ant.

+3

Je ne comprends pas pourquoi le assertEquals le rend plus facile à comparer dans Eclipse? Sûrement n'importe quel outil de diff fera l'affaire? –

Répondre

9

Voici 2 solutions.

propriétés du système d'utilisation

boolean isEclipse() { 
    return System.getProperty("java.class.path").contains("eclipse"); 
} 

Utilisez stacktrace

boolean isEclipse() { 
    Throwable t = new Throwable(); 
    StackTraceElement[] trace = t.getStackTrace(); 
    return trace[trace.length - 1].getClassName().startsWith("org.eclipse"); 
} 
+0

L'approche "Utiliser les propriétés du système" a fonctionné pour moi, merci! –

+0

@AlexR Brillant, je n'ai jamais pensé à instancier une exception pour déterminer le contexte de mon appel en cours. C'est mûr pour abus, mais il semble qu'il y a peut-être des cas où c'est parfait. Merci pour cela. – ArtB

0

Habituellement, les propriétés système sont différentes dans des environnements différents. Essayez de rechercher une propriété système définie uniquement par eclipse ou ant. BTW: La sortie dans Eclipse est la même, c'est juste que la console pour Eclipse rend la sortie sous une forme plus lisible.

Personnellement, je ne m'inquiéterais pas de la taille des bûches. Généralement, vous n'avez pas besoin de les garder très longtemps et l'espace disque est bon marché.

+0

Ce serait un commentaire intéressant pour la question, mais ce n'est certainement pas une réponse utile. – dolmen

2

Oui - vous pouvez vérifier si certaines propriétés OSGI sont définies (System.getProperty("osgi.instance.area") par exemple). Ils seront vides si junit est démarré par ant en dehors de d'éclipse.

+0

Il est également vide depuis l'intérieur d'Eclipse Juno. :( – dolmen

+0

pourrait bien fonctionner pour org.eclipse.osgi .. cela fonctionne pour le thon – Cshah

0

Avec Java 1.6+, il semble que le résultat de System.console() fait une différence entre l'exécution d'Eclipse ou d'un terminal:

boolean isRealTerminal() 
{ 
    // Java 1.6+ 
    return System.console() != null; 
} 
1

Peut-être que l'approche "java.class.path" peut être faible si vous incluez une jarre d'éclipse dans la chemin.

Une approch alternative pourrait être de tester "sun.java.command" à la place:

Sur ma machine (OpenJDK-8):

sun.java.command org.eclipse.jdt.internal.junit.runner.RemoteTestRunner ... 

Un test possible:

boolean isEclipse() { 
    return System.getProperty("sun.java.command") 
     .startsWith("org.eclipse.jdt.internal.junit.runner.RemoteTestRunner"); 
}