18
Selon le titre, je me demandais s'il y a un mécanisme avec easymock pour tester si une méthode n'a pas été appelée pendant sa durée de vie.EasyMock: tester cette méthode dans Mock n'est pas appelée
A
Répondre
11
Par défaut, Easymock lève une exception pour toutes les méthodes appelées pour lesquelles vous n'avez pas explicitement défini d'attentes.
14
De EasyMock documentation:
Belle Mocks
Sur un Mock Object retourné par simulation() le comportement par défaut pour toutes les méthodes est de jeter un AssertionError pour tous les appels non prévus. Si vous voulez un objet "sympa" qui, par défaut, autorise tous les appels de méthode et renvoie des valeurs vides appropriées (0, null ou false), utilisez plutôt niceMock().
Donc ce que vous demandez est le comportement par défaut.
14
Je sais que cette question est très ancienne, mais j'ai eu la même question que l'OP et a fait quelques recherches. J'ai trouvé la solution suivante:
En ajoutant .andThrow(new AssertionFailedError()).anyTimes(); à la fin de votre déclaration EasyMock, le test échouera lorsque la méthode simulée est appelée. La raison pour laquelle cela vaut mieux que de ne pas utiliser NiceMock et de laisser échouer le test en raison de l'appel de méthode non débloqué est que cela vous permet de tester spécifiquement que la méthode XYZ n'a pas été appelée dans le scénario donné.
Je voudrais donner David Wallace crédit pour cette réponse. J'ai trouvé cette solution dans sa réponse sur le post suivant: Test that void method didn't get called with EasyMock
+2
Je crois que cela devrait être la réponse acceptée. Raison pour laquelle les tests unitaires sont souvent modifiés avec de nouvelles exigences et il est très facile de passer à côté de la raison pour laquelle une attente fictive n'a pas été définie. Cette solution rend l'appel de méthode manquant explicite, exigeant ainsi plus d'attention de la part de la personne qui change le code. – mindreader
Questions connexes
- 1. Comment tester cette méthode Sinatra?
- 2. Comment attendre qu'une méthode Mock soit appelée "Any" nombre de fois dans Groovy
- 3. création d'objet Mock dans une méthode
- 4. Comment tester unitairement cette méthode?
- 5. Test que la méthode void n'a pas été appelée avec EasyMock
- 6. Comment puis-je tester si la même méthode est appelée avec les paramètres corrects avec PHPUnit et objet mock
- 7. Comment tester si une méthode de service fluide est appelée
- 8. Mock Runtime.getRuntime()?
- 9. JUnit Easymock Appel de méthode inattendue
- 10. Mock HttpContext.Current dans Test Init, méthode
- 11. Test d'une méthode appelée plusieurs fois dans moq
- 12. méthode invoquée ou méthode appelée?
- 13. Comment tester cette unité?
- 14. Pourquoi la méthode drawRect n'est pas appelée?
- 15. La méthode Objective-C n'est pas appelée
- 16. Pourquoi ma méthode C# n'est pas appelée?
- 17. Que dois-je faire pour tester les objets EasyMock lors de l'utilisation de Generics? EasyMock
- 18. méthode est appelée
- 19. Test si une méthode protégée a été appelée
- 20. Devrais-je utiliser un moq juste pour tester si une méthode est appelée?
- 21. Comment tester l'ordre des appels moquaient en utilisant EasyMock
- 22. Java Stack/Nest Count
- 23. Easymock partiellement moqueur (EasyMock ClassExtension), bon ou mauvais?
- 24. Pourquoi ma méthode CreateRibbonExtensibilityObject n'est-elle pas appelée?
- 25. Comment tester si l'augmentation d'un événement entraîne une méthode appelée conditionnelle à la valeur des paramètres
- 26. Tester si une fonction est appelée en utilisant Mocha
- 27. Equivalent de LastCall.IgnoreArguments dans EasyMock
- 28. La méthode to_json personnalisée n'est pas appelée dans l'application Rails
- 29. La méthode Dealloc n'est pas appelée dans rejectModelViewController?
- 30. La méthode de délégué CLLocationManager n'est pas appelée dans iOS4
Je trouve le comportement par défaut agaçant car vous finissez très facilement par "exiger" dans le test que le code testé est inefficace. J'ai déjà fait un simple refactor de déplacer un appel getSomething() en dehors d'une boucle, ce qui a fait échouer le test parce que je n'ai pas appelé getSomething 40 fois (!), Et les mocks "non sympas" encouragent ce type de test échouerait si je m'attendais à un seul appel avant le refactoring). –
@Stein: convenu. Les tests unitaires doivent être à grain fin, idéalement tester une seule chose. Les mocks "non-sympathiques" découragent cela. –
D'après ma lecture de la question, le PO veut un simulacre qui échouera à la vérification s'il est appelé. Les jolies mocks ne sont pas ce que l'OP veut, car quand un joli simulacre est appelé pendant les tests, il passe encore la vérification. –