24 votes

jUnit ignore les méthodes @Test de la classe de base

Supposons que j'aie une classe de test appelée testFixtureA avec plusieurs méthodes testA , testB , testC etc, chacun avec @Test annotation.

Supposons maintenant que je sous-classe testFixtureA dans une classe appelée testFixtureAB et je n'écrase rien. testFixtureAB est vide pour l'instant.

Lorsque j'exécute des tests à partir de testFixtureAB , méthodes testA , testB y testC sont exécutées par le programme de test car celui-ci ne fait pas de distinction entre les méthodes de test de la classe et celles de la classe de base.

Comment puis-je forcer l'exécution des tests à laisser de côté les tests de la classe de base ?

1voto

Yishai Points 42417

Dans la dernière version de JUnit, vous pouvez utiliser l'annotation @Rule sur la sous-classe pour inspecter le nom du test et intercepter l'exécution du test afin d'ignorer le test de manière dynamique. Mais je dirais que l'idée de @Bozho est la meilleure - le fait que vous ayez besoin de faire cela indique un problème plus important qui montre probablement que l'héritage n'est pas la bonne solution ici.

1voto

topchef Points 7473

Je sais, ce n'est pas la solution...

Réfléchissez à la raison pour laquelle vous étendez les classes de test concrètes. Cela permet de dupliquer les méthodes de test.

Si vous partagez du code entre les tests, envisagez d'écrire des classes de test de base avec méthodes d'aide et d'installation des appareils ou classe d'aide au test .

Si c'est pour exécuter des tests, essayez d'organiser les tests avec des suites et des catégories .

1voto

martosoler Points 81

Que faire si vous souhaitez exécuter le même test pour différentes configurations de la même suite de tests ?

Par exemple, disons que vous avez une classe A avec des méthodes test1, test2 et test3 qui touchent une base de données intégrée. Vous voulez alors créer des "setUp" et "tearDown" séparés pour chaque fournisseur intégré (H2, HyperSQL, etc.), mais exécuter les mêmes tests pour chacun d'entre eux.

J'aimerais étendre une classe qui contient ces méthodes de test et la configurer dans une sous-classe. Mon problème est que la super classe NE DOIT PAS être considérée comme éligible pour le test runner. Le problème survient lorsque le test runner exécute la super classe et qu'il ne trouve pas les méthodes de setup et de teardown correspondantes, il se plante :(

0voto

Mark Mosher Points 1

Dans les méthodes @Test de la classe de test de base :

assumeTrue(getClass().equals(BaseClassTest.class));

Il ignorera les tests de sous-classe, mais ne les laissera pas complètement de côté.

0voto

Ermal Points 91

Si, pour une raison quelconque, vous avez besoin de deux classes JUnit pour la même fonctionnalité, la meilleure approche pour moi est la suivante :

  • placer le code commun dans une classe mère TestFixture avec seulement des constantes et des services simulés.
  • créer deux sous-classes : TestFixtureA y TestFixtureB

De cette manière, vous n'aurez pas de code dupliqué, ni de doubles exécutions.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X