Donc, je suis extrêmement nouveau dans les tests de logiciels et je cherche à ajouter quelques tests à l'une de mes applications. J'ai une méthode publique AddKeywords () qui le long de la route appelle une méthode privée refumetnvalidoperations (). Cette méthode privée appelle une API externe et compte ~ 50 lignes de code. Comme je le considère comme une méthode un peu complexe, je voudrais tester cela sans avoir à le faire en appelant la méthode AddOutword (). Pourtant, cela ne semble pas être possible (du moins pas si Junit).
Les informations que j'ai examinées suggèrent que le désir de tester ses méthodes privées pourrait être une odeur de code. Certaines personnes suggèrent que cela peut être un signe que cela devrait être refacturé dans une classe distincte et rendue publique. En outre, il existe les suggestions que si vous avez vraiment besoin de faire, vous pouvez faire des modifications à votre code de production par exemple. Changez la visibilité de la méthode privée.
Je ne vois pas vraiment pourquoi j'ai un problème avec ma conception de code actuelle, mais je n'aime pas non plus l'idée d'éditer mon code de production adapté à mes besoins de tests.
Comme je le dis - je suis plutôt nouveau à tester, alors toute aide est très appréciée. Aussi, s'il vous plaît laissez-moi savoir s'il ya plus d'informations supplémentaires, je peux fournir pour aider les réponses.
4 Réponses :
Si c'est Les tests d'unité sont censés être fonctionnalité orientés , pas code orienté . Vous testez des unités de fonctionnalité, pas des unités de code.
Quelle que soit la philosophie, une classe extérieure de votre implémentation ne peut pas accéder à la méthode privée sans pirater la JVM, donc vous n'avez pas de chance - vous devez soit modifier la visibilité de la méthode, faire un privé , il ne peut pas être considéré comme faisant partie de l'API de votre application, de sorte que c'est une odeur de code - lorsque le test se casse, est-ce correct ou non?
protégé Test API La classe de test de l'unité s'étend ou testez la fonction indirectement en appelant les méthodes publiques en l'utilisant.
Si vous ne voulez pas appeler addOutwords () , vous devriez peut-être simplement ajouter une autre méthode publique testtremoveinvalidoperations () , qui appelle simplement le "code> privé" code> reflex () . Vous pouvez supprimer le test à une date ultérieure.
+1 pas une mauvaise idée. Changement mineur: faire des testremoveinvalidoperations () Accès par défaut (paquet) et ajoutez un commentaire pertinent pour clarifier son objectif est juste pour les tests d'unités.
-1 Il n'est jamais une bonne idée de piquer des trous dans votre code juste pour tester. Vous devez tester ce que vous avez, pas ce que vous voulez avoir. En outre, de bons tests ont tendance à exiger un bon design. Si le test veut que vous le refactorisez, c'est probablement raison. Et tester un morceau de code compliqué est plus que juste.
Certes, vous devez vous assurer de supprimer le code de test avant de libérer les fichiers au public. Quitter le code public est une mauvaise idée!
Je suggère de le refactoriser.
Une solution rapide que j'ai souvent utilisée consiste à modifier l'accès de Private à Parfait (Package) et de commentaire
// Accès au paquet pour les tests d'unités uniquement. Si cela est acceptable dépend de vos normes de codage et de la quantité Vous faites confiance à vos collègues programmeurs pour comprendre que cette méthode, même si l'accès au paquet n'est pas une "réelle API".