J'écris des tests unitaires et je veux utiliser JUnitParamsRunner
et MockitoJUnitRunner
pour une classe de test.
Malheureusement, ce qui suit ne fonctionne pas:
@RunWith(MockitoJUnitRunner.class)
@RunWith(JUnitParamsRunner.class)
public class DatabaseModelTest {
// some tests
}
Existe-t-il un moyen d'utiliser à la fois Mockito et JUnitParams dans une classe de test?
java
unit-testing
junit
Hans-Helge
la source
la source
Réponses:
Vous ne pouvez pas faire cela car, selon les spécifications, vous ne pouvez pas placer la même annotation deux fois sur le même élément annoté.
Alors, quelle est la solution? La solution est d'en mettre un seul
@RunWith()
avec un coureur dont vous ne pouvez pas vous passer et de remplacer un autre par autre chose. Dans votre cas, je suppose que vous supprimerezMockitoJUnitRunner
et ferez par programme ce qu'il fait.En fait, la seule chose qu'il fait, c'est s'exécuter:
au début du cas de test. Donc, la solution la plus simple est de mettre ce code en
setUp()
méthode:Je ne suis pas sûr, mais vous devriez probablement éviter les appels multiples de cette méthode en utilisant flag:
Cependant, une meilleure solution réutilisable peut être implémentée avec les règles de JUnt.
Maintenant, ajoutez simplement la ligne suivante à votre classe de test:
et vous pouvez exécuter ce cas de test avec n'importe quel coureur de votre choix.
la source
mockInitialized
est faux. Vous voulez avoir une nouvelle maquette pour chaque tétst.Depuis JUnit 4.7 et Mockito 1.10.17, cette fonctionnalité est intégrée; il y a une
org.mockito.junit.MockitoRule
classe. Vous pouvez simplement l'importer et ajouter la ligneà votre classe de test.
la source
@Rule public MockitoJUnitRule mockito = new MockitoJUnitRule(this);
MockitoAnnotations.initMocks(this)
est très lent à créer des simulations. Le moyen le plus efficace est d'utiliser le @Runwith (MockitoJunitRunner.class)Cette solution fonctionne pour tous les coureurs possibles, pas seulement pour cet exemple de simulation. Par exemple; pour Spring, changez simplement les classes de coureurs et ajoutez les annotations nécessaires.
DatabaseModelTest
sera exécuté par JUnit.TestMockitoJUnitRunner
en dépend (par logique) et il sera exécuté à l' intérieur du main dans une@Test
méthode, lors de l'appelJUnitCore.runClasses(TestMockitoJUnitRunner.class)
. Cette méthode garantit que le programme d'static class TestMockitoJUnitRunner
exécution principal est démarré correctement avant l' exécution du sous-programme, implémentant efficacement plusieurs@RunWith
annotations imbriquées avec des classes de test dépendantes.Aussi sur https://bekce.github.io/junit-multiple-runwith-dependent-tests
la source
JUnitCore.runClasses()
sans inspecter le résultat, vous risquez de masquer les erreurs du test interne.assert(JUnitCore.runClasses(TestMockitoJUnitRunner.class).wasSuccessful());
vous signalera au moins l'erreurDepuis la sortie de PowerMock 1.6, vous pouvez le faire aussi facilement que
Expliqué ici https://blog.jayway.com/2014/11/29/using-another-junit-runner-with-powermock/
la source
Dans mon cas, j'essayais de simuler une méthode dans le haricot de printemps et
ne fonctionne pas. Au lieu de cela, vous devez définir ce bean comme étant construit en utilisant la méthode fictive dans votre fichier xml comme suit.
et ajoutez ce bean avec autowired dans votre classe de test comme suit.
la source
consultez ce lien https://bekce.github.io/junit-multiple-runwith-dependent-tests/ en utilisant cette approche j'ai combiné un @RunWith (Parameterized.class) - coureur externe - avec @RunWith (MockitoJUnitRunner.class) - coureur intérieur. Le seul ajustement que j'ai dû ajouter était de rendre statiques mes variables membres dans la classe externe / le coureur afin de les rendre accessibles pour le coureur / la classe interne / imbriqué. porte chance et profite.
la source
Je voulais exécuter SWTBotJunit4ClassRunner et org.junit.runners.Parameterized en même temps, j'ai des tests paramétriques et je veux faire des captures d'écran lorsque le test SWT échoue (la fonction de capture d'écran est fournie par SWTBotJunit4ClassRunner ). La réponse de @ bekce est excellente et voulait d'abord emprunter cette voie, mais c'était soit excentrique en passant par les arguments. Ou faire le paramétré dans la sous-classe et perdre les informations sur les tests exacts qui ont réussi / échoué et n'ont que la dernière capture d'écran (car les noms de capture d'écran obtiennent le nom du test lui-même). De toute façon, c'était un peu compliqué.
Dans mon cas, le SWTBotJunit4ClassRunner est assez simple, donc j'ai cloné le code source de la classe, lui ai donné mon propre nom ParametrizedScreenshotRunner et là où l'original étendait le TestRunner , ma classe étend le Parameterized classe donc en substance je peux utiliser mon propre coureur au lieu des deux précédents. En résumé, mon propre coureur s'étend au-dessus du coureur paramétré tout en implémentant la fonction de capture d'écran par-dessus, maintenant mon test utilise ce coureur "hybride" et tous les tests fonctionnent immédiatement comme prévu (pas besoin de changer quoi que ce soit dans les tests).
Voici à quoi cela ressemble (par souci de concision, j'ai supprimé tous les commentaires de la liste):
la source
Vous pouvez également essayer ceci:
la source