Comment tester une classe qui a des méthodes privées, des champs ou des classes internes ?

Question

Comment utiliser JUnit pour tester une classe qui contient des méthodes, des champs ou des classes imbriquées privées?

Il semble inapproprié de changer le modificateur d'accès d'une méthode juste pour pouvoir exécuter un test.

Answer 1

Si vous avez quelque chose d'hérité d'une application Java, et que vous n'êtes pas autorisé à changer la visibilité de vos méthodes, la meilleure façon de tester les méthodes privées est d'utiliser la réflexion.

En interne, nous utilisons des aides pour obtenir/définir des variables private et private static ainsi que pour invoquer des méthodes private et private static. Les motifs suivants vous permettront de faire à peu près tout ce qui concerne les méthodes privées et les champs. Bien sûr, vous ne pouvez pas changer les variables private static final via la réflexion.

Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);

Et pour les champs:

Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);

---

Notes:

1. TargetClass.getDeclaredMethod(methodName, argClasses) vous permet d'examiner les méthodes private. La même chose s'applique pour getDeclaredField.
2. setAccessible(true) est requis pour jouer avec les éléments privés.

Answer 2

La meilleure façon de tester une méthode privée est via une autre méthode publique. Si cela ne peut pas être fait, alors l'une des conditions suivantes est vraie:

1. La méthode privée est du code mort
2. Il y a une odeur de conception près de la classe que vous testez
3. La méthode que vous essayez de tester ne devrait pas être privée

Answer 3

Quand j'ai des méthodes privées dans une classe qui sont suffisamment compliquées pour que j'ai besoin de tester les méthodes privées directement, c'est une odeur de code : ma classe est trop compliquée.

Ma démarche habituelle pour résoudre de tels problèmes est d'extraire une nouvelle classe qui contient les parties intéressantes. Souvent, cette méthode et les champs avec lesquels elle interagit, et peut-être une autre méthode ou deux peuvent être extraites dans une nouvelle classe.

La nouvelle classe expose ces méthodes comme \'public\', donc elles sont accessibles pour les tests unitaires. Les nouvelles et anciennes classes sont maintenant toutes deux plus simples que la classe originale, ce qui est génial pour moi (j'ai besoin de garder les choses simples, sinon je me perds!).

Remarquez que je ne suggère pas aux gens de créer des classes sans utiliser leur cerveau! Le point ici est d'utiliser les forces des tests unitaires pour vous aider à trouver de bonnes nouvelles classes.

Answer 4

J'ai utilisé la réflexion pour faire cela pour Java dans le passé, et à mon avis c'était une grosse erreur.

Strictement parlant, vous ne devriez pas écrire des tests unitaires qui testent directement les méthodes privées. Ce que vous devriez tester est le contrat public que la classe a avec d'autres objets; vous ne devriez jamais tester directement les parties internes d'un objet. Si un autre développeur veut apporter une petite modification interne à la classe, qui n'affecte pas le contrat public de la classe, il doit alors modifier votre test basé sur la réflexion pour s'assurer qu'il fonctionne. Si vous faites cela de manière répétée tout au long d'un projet, les tests unitaires cessent alors d'être une mesure utile de la santé du code, et commencent à devenir un obstacle au développement, et une source de frustration pour l'équipe de développement.

Ce que je recommande plutôt, c'est d'utiliser un outil de couverture de code, tel que Cobertura, pour vous assurer que les tests unitaires que vous écrivez offrent une bonne couverture du code dans les méthodes privées. De cette manière, vous testez indirectement ce que font les méthodes privées, et maintenez un niveau plus élevé d'agilité.

Answer 5

À partir de cet article: Testing Private Methods with JUnit and SuiteRunner (Bill Venners), vous avez essentiellement 4 options:

1. Ne testez pas les méthodes privées.
2. Donnez accès aux méthodes du package.
3. Utilisez une classe de test imbriquée.
4. Utilisez la réflexion.