pour rendre une méthode privée publique uniquement pour les classes de test

Question

Qui a une solution pour ce besoin commun.

J'ai une classe dans mon application.

certaines méthodes sont publiques, car elles font partie de l'interface utilisateur, et d'autres sont privées, car elles servent à rendre le flux interne plus lisible.

Maintenant, disons que je veux écrire un test unitaire, ou plutôt un test d'intégration, qui sera situé dans un paquet différent, qui sera autorisé à appeler cette méthode, MAIS, je veux que l'appel normal à cette méthode ne soit pas autorisé si vous essayez de l'appeler à partir des classes de l'application elle-même.

Je pensais donc à quelque chose comme ça

public class MyClass {

   public void somePublicMethod() {
    ....
   }

   @PublicForTests
   private void somePrivateMethod() {
    ....
   }
}

L'annotation ci-dessus marquera la méthode privée comme "publique pour les tests" ce qui signifie que la compilation et l'exécution seront autorisées pour toute classe faisant partie du package test..., tandis que la compilation et l'exécution seront autorisées pour toute classe faisant partie du package test... \or échouera pour toute classe qui ne fait pas partie du paquetage de test.

Des idées ? Existe-t-il une annotation de ce type ? Existe-t-il une meilleure façon de procéder ?

il semble que plus on écrit de tests unitaires, plus on est obligé de casser l'encapsulation...

Answer 1

La méthode la plus courante consiste à rendre la méthode privée protégée ou privée par paquet et à placer le test unitaire de cette méthode dans le même paquet que la classe testée.

La goyave a une @VisibleForTesting annotation mais c'est uniquement à des fins de documentation.

Answer 2

Si votre couverture de test est bonne sur toutes les méthodes publiques à l'intérieur de la classe testée, les méthodes privées appelées par les méthodes publiques seront automatiquement testées puisque vous aurez affirmé tous les cas possibles.

Le document JUnit dit :

Le fait de tester des méthodes privées peut indiquer que ces méthodes devraient être déplacées dans une autre classe afin de favoriser leur réutilisation. Mais si vous devez le faire... Si vous utilisez le JDK 1.3 ou une version ultérieure, vous pouvez utiliser la réflexion pour subvertir le mécanisme de contrôle d'accès à l'aide du PrivilegedAccessor. Pour plus de détails sur son utilisation, lire cet article.

Answer 3

Envisagez d'utiliser des interfaces pour exposer les méthodes de l'API, d'utiliser des usines ou des DI pour publier les objets afin que les consommateurs ne les connaissent que par l'interface. L'interface décrit l'API publiée. De cette façon, vous pouvez rendre public ce que vous voulez sur les objets d'implémentation et les consommateurs de ces objets ne voient que les méthodes exposées par l'interface.

Answer 4

dp4j a ce qu'il vous faut. Tout ce que vous avez à faire est d'ajouter dp4j à votre classpath et chaque fois qu'une méthode annotée avec @Test (l'annotation de JUnit) appelle une méthode privée, cela fonctionnera (dp4j injectera la réflexion nécessaire au moment de la compilation). Vous pouvez également utiliser l'annotation @TestPrivates de dp4j pour être plus explicite.

Si vous insistez pour annoter également vos méthodes privées, vous pouvez utiliser l'annotation @VisibleForTesting de Google.

Answer 5

Un article sur Test des méthodes privées L'utilisation de la réflexion impose un fardeau supplémentaire au programmeur qui doit se rappeler si un remaniement est effectué, les chaînes de caractères ne sont pas automatiquement modifiées, mais je pense qu'il s'agit de l'approche la plus propre.