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

Comment puis-je tester unitaire (en utilisant xUnit) une classe qui a des méthodes privées internes, des champs ou des classes imbriquées? Ou une fonction rendue privée par un lien interne ( staticen C / C ++) ou se trouvant dans un espace de noms privé ( anonyme )?

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

Mise à jour:

Une dizaine d'années plus tard, la meilleure façon de tester une méthode privée ou tout membre inaccessible est via @Jailbreakle framework Manifold .

@Jailbreak Foo foo = new Foo();
// Direct, *type-safe* access to *all* foo's members
foo.privateMethod(x, y, z);
foo.privateField = value;

De cette façon, votre code reste sûr et lisible. Pas de compromis de conception, pas de méthodes et de champs de surexposition pour les besoins des tests.

Si vous disposez d'une application Java héritée et que vous n'êtes pas autorisé à modifier la visibilité de vos méthodes, la meilleure façon de tester des méthodes privées consiste à utiliser la réflexion .

En interne, nous utilisons des assistants pour obtenir / définir privateet les private staticvariables ainsi que pour appeler privateet les private staticméthodes. Les modèles suivants vous permettront de faire à peu près tout ce qui concerne les méthodes et les champs privés. Bien sûr, vous ne pouvez pas modifier les private static finalvariables par 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);

Remarques:
1. TargetClass.getDeclaredMethod(methodName, argClasses)vous permet d'examiner les privateméthodes. La même chose s'applique pour getDeclaredField.
2. Le setAccessible(true)est requis pour jouer avec des soldats.

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, l'une des conditions suivantes est remplie:

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

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

Mon approche habituelle pour résoudre ces problèmes est de révéler une nouvelle classe qui contient les bits intéressants. Souvent, cette méthode et les champs avec lesquels elle interagit, et peut-être qu'une ou deux autres méthodes peuvent être extraites dans une nouvelle classe.

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

Notez que je ne suggère pas que les gens créent 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.

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

À strictement parler, vous ne devez pas écrire des tests unitaires qui testent directement des méthodes privées. Ce que vous devriez tester, c'est le contrat public que la classe a avec d'autres objets; vous ne devez jamais tester directement les éléments internes d'un objet. Si un autre développeur souhaite apporter une petite modification interne à la classe, ce qui n'affecte pas le contrat public des classes, il / elle doit alors modifier votre test basé sur la réflexion pour s'assurer qu'il fonctionne. Si vous le faites à plusieurs reprises 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 gêne pour l'équipe de développement.

Ce que je recommande à la place, c'est d'utiliser un outil de couverture de code tel que Cobertura, pour garantir que les tests unitaires que vous écrivez fournissent une couverture décente du code dans des méthodes privées. De cette façon, vous testez indirectement ce que font les méthodes privées et maintenez un niveau d'agilité plus élevé.

De cet article: Tester des méthodes privées avec JUnit et SuiteRunner (Bill Venners), vous avez essentiellement 4 options:

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

Généralement, un test unitaire est destiné à exercer l'interface publique d'une classe ou d'une unité. Par conséquent, les méthodes privées sont des détails d'implémentation que vous ne vous attendez pas à tester explicitement.

Juste deux exemples où je voudrais tester une méthode privée:

1. Routines de déchiffrement - Je ne voudrais pas les rendre visibles à quiconque pour voir juste pour le test, sinon n'importe qui peut les utiliser pour déchiffrer. Mais ils sont intrinsèques au code, compliqués et doivent toujours fonctionner (l'exception évidente est la réflexion qui peut être utilisée pour afficher même les méthodes privées dans la plupart des cas, lorsqu'elle SecurityManagern'est pas configurée pour empêcher cela).
2. Création d'un SDK pour la consommation communautaire. Ici, le public prend un sens complètement différent, car il s'agit d'un code que le monde entier peut voir (pas seulement à l'intérieur de mon application). Je mets du code dans des méthodes privées si je ne veux pas que les utilisateurs du SDK le voient - je ne vois pas cela comme une odeur de code, mais simplement comme le fonctionnement de la programmation du SDK. Mais bien sûr, je dois encore tester mes méthodes privées, et c'est là que les fonctionnalités de mon SDK se trouvent réellement.

Je comprends l'idée de ne tester que le "contrat". Mais je ne vois pas que l'on puisse préconiser de ne pas tester le code - votre kilométrage peut varier.

Mon compromis consiste donc à compliquer les JUnits avec réflexion, plutôt qu'à compromettre ma sécurité et mon SDK.

Les méthodes privées sont appelées par une méthode publique, donc les entrées de vos méthodes publiques doivent également tester les méthodes privées qui sont appelées par ces méthodes publiques. Lorsqu'une méthode publique échoue, cela peut être un échec dans la méthode privée.

Une autre approche que j'ai utilisée consiste à changer une méthode privée pour empaqueter privé ou protégé, puis à la compléter avec l' annotation @VisibleForTesting de la bibliothèque Google Guava.

Cela indiquera à quiconque utilisant cette méthode de prendre des précautions et de ne pas y accéder directement, même dans un package. De même, une classe de test n'a pas besoin d'être physiquement dans le même package , mais dans le même package sous le dossier de test .

Par exemple, si une méthode à tester est présente, src/main/java/mypackage/MyClass.javavotre appel de test doit être placé src/test/java/mypackage/MyClassTest.java. De cette façon, vous avez accès à la méthode de test dans votre classe de test.

Pour tester du code hérité avec des classes volumineuses et originales, il est souvent très utile de pouvoir tester la seule méthode privée (ou publique) que j'écris en ce moment .

J'utilise le package junitx.util.PrivateAccessor pour Java. Beaucoup de lignes utiles pour accéder aux méthodes privées et aux champs privés.

import junitx.util.PrivateAccessor;

PrivateAccessor.setField(myObjectReference, "myCrucialButHardToReachPrivateField", myNewValue);
PrivateAccessor.invoke(myObjectReference, "privateMethodName", java.lang.Class[] parameterTypes, java.lang.Object[] args);

Dans Spring Framework, vous pouvez tester des méthodes privées à l'aide de cette méthode:

ReflectionTestUtils.invokeMethod()

Par exemple:

ReflectionTestUtils.invokeMethod(TestClazz, "createTest", "input data");

Après avoir essayé la solution de Cem Catikkas en utilisant la réflexion pour Java, je dois dire que c'était une solution plus élégante que celle que j'ai décrite ici. Cependant, si vous cherchez une alternative à l'utilisation de la réflexion et avez accès à la source que vous testez, ce sera toujours une option.

Il est possible de tester les méthodes privées d'une classe, en particulier avec le développement piloté par les tests , où vous souhaitez concevoir de petits tests avant d'écrire du code.

La création d'un test avec accès aux membres privés et aux méthodes peut tester des zones de code difficiles à cibler spécifiquement avec un accès uniquement aux méthodes publiques. Si une méthode publique comporte plusieurs étapes, elle peut consister en plusieurs méthodes privées, qui peuvent ensuite être testées individuellement.

Avantages:

• Peut tester une granularité plus fine

Désavantages:

• Le code de test doit résider dans le même fichier que le code source, ce qui peut être plus difficile à maintenir
• De même avec les fichiers de sortie .class, ils doivent rester dans le même package que celui déclaré dans le code source

Cependant, si des tests continus nécessitent cette méthode, cela peut être un signal que les méthodes privées doivent être extraites, qui pourraient être testées de manière traditionnelle et publique.

Voici un exemple compliqué de la façon dont cela fonctionnerait:

// Import statements and package declarations

public class ClassToTest
{
    private int decrement(int toDecrement) {
        toDecrement--;
        return toDecrement;
    }

    // Constructor and the rest of the class

    public static class StaticInnerTest extends TestCase
    {
        public StaticInnerTest(){
            super();
        }

        public void testDecrement(){
            int number = 10;
            ClassToTest toTest= new ClassToTest();
            int decremented = toTest.decrement(number);
            assertEquals(9, decremented);
        }

        public static void main(String[] args) {
            junit.textui.TestRunner.run(StaticInnerTest.class);
        }
    }
}

La classe interne serait compilée pour ClassToTest$StaticInnerTest.

Voir aussi: Astuce Java 106: classes internes statiques pour le plaisir et le profit

Comme d'autres l'ont dit ... ne testez pas directement les méthodes privées. Voici quelques réflexions:

1. Gardez toutes les méthodes petites et ciblées (faciles à tester, faciles à trouver ce qui ne va pas)
2. Utilisez des outils de couverture de code. J'aime Cobertura (oh happy day, on dirait qu'une nouvelle version est sortie!)

Exécutez la couverture du code sur les tests unitaires. Si vous voyez que les méthodes ne sont pas entièrement testées, ajoutez aux tests pour augmenter la couverture. Visez une couverture de code à 100%, mais réalisez que vous ne l'obtiendrez probablement pas.

Les méthodes privées sont consommées par les méthodes publiques. Sinon, ce sont des codes morts. C'est pourquoi vous testez la méthode publique, affirmant les résultats attendus de la méthode publique et donc les méthodes privées qu'elle consomme.

Le test des méthodes privées doit être testé par débogage avant d'exécuter vos tests unitaires sur les méthodes publiques.

Ils peuvent également être débogués à l'aide d'un développement piloté par les tests, déboguant vos tests unitaires jusqu'à ce que toutes vos assertions soient satisfaites.

Je pense personnellement qu'il vaut mieux créer des classes en utilisant TDD; créer les talons de méthode publique, puis générer des tests unitaires avec toutes les assertions définies à l'avance, de sorte que le résultat attendu de la méthode soit déterminé avant de la coder. De cette façon, vous n'allez pas dans la mauvaise direction pour que les assertions des tests unitaires correspondent aux résultats. Votre classe est alors robuste et répond aux exigences lorsque tous vos tests unitaires réussissent.

Si vous utilisez Spring, ReflectionTestUtils fournit des outils pratiques qui vous aident ici avec un effort minimal. Par exemple, pour configurer une maquette sur un membre privé sans être obligé d'ajouter un setter public indésirable:

ReflectionTestUtils.setField(theClass, "theUnsettableField", theMockObject);

Si vous essayez de tester du code existant que vous êtes réticent ou incapable de changer, la réflexion est un bon choix.

Si la conception de la classe est toujours flexible et que vous avez une méthode privée compliquée que vous souhaitez tester séparément, je vous suggère de la retirer dans une classe distincte et de tester cette classe séparément. Cela ne doit pas changer l'interface publique de la classe d'origine; il peut créer en interne une instance de la classe d'assistance et appeler la méthode d'assistance.

Si vous souhaitez tester des conditions d'erreur difficiles provenant de la méthode d'assistance, vous pouvez aller plus loin. Extraire une interface de la classe d'assistance, ajouter un getter et un setter publics à la classe d'origine pour injecter la classe d'assistance (utilisée via son interface), puis injecter une version fictive de la classe d'assistance dans la classe d'origine pour tester le fonctionnement de la classe d'origine répond aux exceptions de l'aide. Cette approche est également utile si vous souhaitez tester la classe d'origine sans également tester la classe d'assistance.

Le test des méthodes privées rompt l'encapsulation de votre classe car chaque fois que vous modifiez l'implémentation interne, vous cassez le code client (dans ce cas, les tests).

Alors ne testez pas les méthodes privées.

La réponse de la page FAQ de JUnit.org :

Mais si vous devez ...

Si vous utilisez JDK 1.3 ou supérieur, vous pouvez utiliser la réflexion pour renverser le mécanisme de contrôle d'accès à l'aide de PrivilegedAccessor . Pour plus de détails sur son utilisation, lisez cet article .

Si vous utilisez JDK 1.6 ou supérieur et que vous annotez vos tests avec @Test, vous pouvez utiliser Dp4j pour injecter de la réflexion dans vos méthodes de test. Pour plus de détails sur son utilisation, consultez ce script de test .

PS Je suis le principal contributeur de Dp4j , demandez- moi si vous avez besoin d'aide. :)

Si vous souhaitez tester des méthodes privées d'une application héritée où vous ne pouvez pas modifier le code, une option pour Java est jMockit , qui vous permettra de créer des simulations sur un objet même lorsqu'elles sont privées pour la classe.

J'ai tendance à ne pas tester de méthodes privées. Là réside la folie. Personnellement, je pense que vous ne devriez tester que vos interfaces exposées publiquement (et cela inclut les méthodes protégées et internes).

Si vous utilisez JUnit, jetez un œil aux add-ons junit . Il a la capacité d'ignorer le modèle de sécurité Java et d'accéder aux méthodes et attributs privés.

Je vous suggère de refactoriser un peu votre code. Lorsque vous devez commencer à penser à utiliser la réflexion ou d'autres types de choses, pour simplement tester votre code, quelque chose ne va pas avec votre code.

Vous avez mentionné différents types de problèmes. Commençons par les champs privés. Dans le cas de champs privés, j'aurais ajouté un nouveau constructeur et injecté des champs dans celui-ci. Au lieu de cela:

public class ClassToTest {

    private final String first = "first";
    private final List<String> second = new ArrayList<>();
    ...
}

J'aurais utilisé ceci:

public class ClassToTest {

    private final String first;
    private final List<String> second;

    public ClassToTest() {
        this("first", new ArrayList<>());
    }

    public ClassToTest(final String first, final List<String> second) {
        this.first = first;
        this.second = second;
    }
    ...
}

Ce ne sera pas un problème, même avec du code hérité. L'ancien code utilisera un constructeur vide, et si vous me le demandez, le code refactorisé sera plus propre et vous pourrez injecter les valeurs nécessaires dans le test sans réflexion.

Maintenant sur les méthodes privées. D'après mon expérience personnelle, lorsque vous devez écraser une méthode privée pour les tests, cette méthode n'a rien à voir dans cette classe. Un modèle commun, dans ce cas, serait de l' envelopper dans une interface, comme Callableet vous passez ensuite cette interface également dans le constructeur (avec cette astuce de constructeur multiple):

public ClassToTest() {
    this(...);
}

public ClassToTest(final Callable<T> privateMethodLogic) {
    this.privateMethodLogic = privateMethodLogic;
}

La plupart du temps, tout ce que j'ai écrit ressemble à un schéma d'injection de dépendance. D'après mon expérience personnelle, c'est vraiment utile lors des tests, et je pense que ce type de code est plus propre et sera plus facile à maintenir. Je dirais la même chose des classes imbriquées. Si une classe imbriquée contient une logique lourde, il serait préférable de la déplacer en tant que classe privée de package et de l'injecter dans une classe qui en a besoin.

Il existe également plusieurs autres modèles de conception que j'ai utilisés lors de la refactorisation et de la maintenance du code hérité, mais tout dépend des cas de votre code à tester. L'utilisation de la réflexion n'est généralement pas un problème, mais lorsque vous avez une application d'entreprise qui est fortement testée et que les tests sont exécutés avant chaque déploiement, tout devient vraiment lent (c'est juste ennuyeux et je n'aime pas ce genre de choses).

Il y a aussi l'injection de setter, mais je ne recommanderais pas de l'utiliser. Je préfère m'en tenir à un constructeur et initialiser tout quand c'est vraiment nécessaire, en laissant la possibilité d'injecter les dépendances nécessaires.

Une méthode privée n'est accessible que dans la même classe. Il n'y a donc aucun moyen de tester une méthode «privée» d'une classe cible à partir d'une classe de test. Une solution consiste à effectuer manuellement des tests unitaires ou à changer votre méthode de «privé» à «protégé».

Et puis une méthode protégée n'est accessible que dans le même package où la classe est définie. Donc, tester une méthode protégée d'une classe cible signifie que nous devons définir votre classe de test dans le même package que la classe cible.

Si tout ce qui précède ne correspond pas à vos besoins, utilisez la méthode de réflexion pour accéder à la méthode privée.

Comme beaucoup l'ont suggéré ci-dessus, un bon moyen est de les tester via vos interfaces publiques.

Si vous faites cela, c'est une bonne idée d'utiliser un outil de couverture de code (comme Emma) pour voir si vos méthodes privées sont en fait exécutées à partir de vos tests.

Voici ma fonction générique pour tester des champs privés:

protected <F> F getPrivateField(String fieldName, Object obj)
    throws NoSuchFieldException, IllegalAccessException {
    Field field =
        obj.getClass().getDeclaredField(fieldName);

    field.setAccessible(true);
    return (F)field.get(obj);
}

Veuillez voir ci-dessous pour un exemple;

La déclaration d'importation suivante doit être ajoutée:

import org.powermock.reflect.Whitebox;

Vous pouvez maintenant passer directement l'objet qui a la méthode privée, le nom de la méthode à appeler et des paramètres supplémentaires comme ci-dessous.

Whitebox.invokeMethod(obj, "privateMethod", "param1");

Aujourd'hui, j'ai poussé une bibliothèque Java pour aider à tester des méthodes et des champs privés. Il a été conçu avec Android à l'esprit, mais il peut vraiment être utilisé pour n'importe quel projet Java.

Si vous avez obtenu du code avec des méthodes ou des champs ou des constructeurs privés, vous pouvez utiliser BoundBox . Il fait exactement ce que vous recherchez. Voici ci-dessous un exemple de test qui accède à deux champs privés d'une activité Android pour la tester:

@UiThreadTest
public void testCompute() {

    // Given
    boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity());

    // When
    boundBoxOfMainActivity.boundBox_getButtonMain().performClick();

    // Then
    assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText());
}

BoundBox facilite le test de champs, méthodes et constructeurs privés / protégés. Vous pouvez même accéder à des éléments cachés par héritage. En effet, BoundBox rompt l'encapsulation. Il vous donnera accès à tout cela grâce à la réflexion, MAIS tout est vérifié au moment de la compilation.

Il est idéal pour tester du code hérité. Utilisez-le soigneusement. ;)

https://github.com/stephanenicolas/boundbox

Tout d'abord, je vais jeter cette question: pourquoi vos membres privés ont-ils besoin de tests isolés? Sont-ils si complexes, offrant des comportements compliqués au point de nécessiter des tests en dehors de la surface publique? Ce sont des tests unitaires, pas des tests de «ligne de code». Ne transpirez pas les petites choses.

S'ils sont si grands, assez grands pour que ces membres privés soient chacun une «unité» de grande complexité - pensez à refactoriser ces membres privés de cette classe.

Si la refactorisation est inappropriée ou irréalisable, pouvez-vous utiliser le modèle de stratégie pour remplacer l'accès à ces fonctions / classes membres privées lors d'un test unitaire? Dans le cadre d'un test unitaire, la stratégie fournirait une validation supplémentaire, mais dans les versions de version, ce serait un simple passthrough.

J'ai récemment eu ce problème et j'ai écrit un petit outil, appelé Picklock , qui évite les problèmes d'utilisation explicite de l'API de réflexion Java, deux exemples:

Méthodes d'appel, par exemple private void method(String s)- par réflexion Java

Method method = targetClass.getDeclaredMethod("method", String.class);
method.setAccessible(true);
return method.invoke(targetObject, "mystring");

Méthodes d'appel, par exemple private void method(String s)- par Picklock

interface Accessible {
  void method(String s);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.method("mystring");

Définition de champs, par exemple private BigInteger amount;- par réflexion Java

Field field = targetClass.getDeclaredField("amount");
field.setAccessible(true);
field.set(object, BigInteger.valueOf(42));

Définition de champs, par exemple private BigInteger amount;- par Picklock

interface Accessible {
  void setAmount(BigInteger amount);
}

...
Accessible a = ObjectAccess.unlock(targetObject).features(Accessible.class);
a.setAmount(BigInteger.valueOf(42));

PowerMockito est fait pour cela. Utiliser la dépendance maven

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-mockito-release-full</artifactId>
    <version>1.6.4</version>
</dependency>

Ensuite, vous pouvez faire

import org.powermock.reflect.Whitebox;
...
MyClass sut = new MyClass();
SomeType rval = Whitebox.invokeMethod(sut, "myPrivateMethod", params, moreParams);