J'ai une classe comme celle-ci: Veuillez noter que getbar () est implémenté avec JNI et que la classe est finale . Je veux écrire un test Junit pour tester la méthode Tostring () . Pour cela, j'ai besoin de se moquer de la méthode getbar () puis d'exécuter la méthode d'origine tostring () pour vérifier la sortie. Ma première pensée était que cela doit être impossible, mais j'ai trouvé PowerMock qui prend en charge tester les classes finales et les méthodes natives en fonction de la liste des caractéristiques. Mais jusqu'à présent, je n'ai eu aucun succès avec ça. La meilleure chose que j'ai gérée était moquée de la classe complète, mais le test a été testé la méthode moquée Tostring () au lieu du réel qui n'a pas beaucoup de sens. alors comment Puis-je utiliser PowerMock pour tester cette méthode tostring () d'en haut? Je préfère utiliser PowerMock avec Mockito mais si cela n'est pas possible, je n'ai aucun problème à utiliser EasyMock à la place.
3 Réponses :
trouvé. La façon dont je faisais c'était correct. La seule chose que j'ai manquée consistait à dire à l'objet moqueur d'appeler la méthode originale lorsque vous appuyez sur Tostring (). Donc cela fonctionne comme ceci:
Salut ... je ne peux pas ajouter le "quand ()" .. pourquoi ..? Pouvez-vous s'il vous plaît dites-moi en utilisant EasyMock
ou utilisez public final class Foo
{
public IBarStrategy barStrategy;
......
}
interface IBarStrategy{
int getBar();
}
L'injection de dépendance est une chose intéressante pour la réutilisation et la modularité du code, mais si cela n'est pas nécessaire, pourquoi devrais-je augmenter la complexité et desserrer l'API de mes classes juste pour la qualification? Mais ce n'est pas le point ici. Donc, disons-moi que je ne peux pas changer le sujet de test afin que je ne puisse pas extraire les méthodes natales dans une interface.
Vous n'êtes pas en train d'augmenter la complexité en faisant cela. Votre juste cacher la complexité en ne faisant pas cela. Vous devriez concevoir la possibilité de commencer avec