Méthodes privées de test Java

Les méthodes privées de test Java sont définies comme les méthodes ayant un modificateur d'accès privé et sont limitées à un accès dans la classe de définition uniquement et ne sont pas visibles dans leur classe enfant, car elles ne sont pas éligibles au remplacement, cependant, nous pouvons définir une méthode portant le même nom dans la classe enfant et pouvant accéder à la classe parent, peut également tester les méthodes privées en effectuant un accès au package de méthodes privées, ce qui nous permet de les tester directement avec JUnit à partir des classes de test du même package mais le test de les méthodes privées dans SuiteRunner sont plus faciles à tester dans JUnit.

Commencez votre cours de développement de logiciels libres

Développement Web, langages de programmation, tests de logiciels et autres

Liste de quatre approches de base pour tester les méthodes privées

Que vous utilisiez JUnit ou SuiteRunner, nous avons quatre approches de base pour tester les méthodes privées,

1. Ne pas tester les méthodes privées (Tests indirects)

Parfois, la méthode privée effectue une tâche très compliquée et le test doit être très bien testé, nous ne voulons donc pas que les utilisateurs aient accès à ces méthodes, car les méthodes privées doivent être protégées.
Les méthodes privées n'ont pas pu tester indirectement mais seulement leur effet sur les méthodes publiques qui les appellent. Tester des méthodes privées peut indiquer que ces méthodes sont déplacées vers une autre classe qui facilite/supporte la réutilisabilité.

Si nous extrayons la méthode privée à partir de laquelle fonctionnent déjà et a une bonne couverture de tests unitaires, alors celle qui existe déjà dans un test unitaire est suffisante pour tester, nous n'avons donc pas besoin d'écrire plus de tests unitaires pour les méthodes privées. Mais si nous voulons écrire la méthode privée avant sa méthode appelante et que nous voulons écrire les tests unitaires avant d'écrire la méthode privée.

Exemples

public class testClass
{
private String testMethod(String s)
{
return s;
}
}

L'exemple ci-dessus sert uniquement à tester les méthodes privées. Si nous avons une classe « testClass », alors elle est appelée par une méthode comme « testMethod() », alors cette méthode est privée et en passant une chaîne ou un objet, nous pouvons renvoyer la valeur.

2. Donner l'accès au package de méthode

Donner l'accès aux packages de méthodes fonctionne bien pour tester des méthodes privées avec JUnit, mais cela est légèrement coûteux. Lorsqu'une méthode a un modificateur d'accès privé, elle fait partie de l'implémentation de la classe. Nous pouvons ignorer la méthode si nous essayons simplement d'utiliser une classe d'une autre classe dans le package et nous pouvons le comprendre en utilisant la méthode d'accès au package. En outre, le test des méthodes non publiques des classes peut être effectué à l'aide du package d'accès aux méthodes.
La première façon de rendre le package de méthode privé sans modificateur d'accès et de placer les tests dans le même package, c'est une méthode courante mais quand même, si nous voulons un autre code, la deuxième façon est de rendre la méthode publique.

3. Utilisez une classe de test imbriquée

La troisième chose à propos du test des méthodes privées en Java est l'utilisation d'une classe de test imbriquée, cela peut être fait en imbriquant une classe statique dans la classe de production testée. La classe imbriquée a accès au membre privé de sa classe englobante, elle pourrait invoquer directement les méthodes privées. La classe statique elle-même pourrait être un accès au package, lui permettant de faire partie du test de la boîte blanche.
L'inconvénient de cette classe de test imbriquée est que, si nous ne voulons pas que la classe imbriquée soit accessible dans le fichier JAR de notre département, nous devons alors effectuer un travail supplémentaire pour l'extraire. Cela peut être problématique car les analystes qualité apporteront des modifications au code source.

4. Utilisez la réflexion

Venons maintenant à la prochaine utilisation de la réflexion. L’avantage d’utiliser la réflexion pour tester des méthodes privées est qu’elle permet une séparation nette entre le code de test et le code de production. Comme nous le voyons déjà dans l'approche des classes imbriquées, les tests n'ont pas besoin d'être testés à l'intérieur de la classe, dans laquelle la classe est testée, mais ils peuvent être placés aux côtés des autres tests qui exercent le niveau package et les méthodes publiques de la classe. Comme nous utilisons une classe imbriquée, nous n'avons pas besoin d'ajouter de classe imbriquée supplémentaire au niveau d'accès au package.

Reflection est une API utilisée pour examiner ou modifier le comportement des méthodes, classes et interfaces au moment de l'exécution. L'inconvénient de l'utilisation de la réflexion est que le code de test est bien plus fastidieux car il utilise l'API de réflexion.

Exemple : programme Java pour décrire l'utilisation de la réflexion

Code :

import java.lang.reflect.Method;
import java.lang.reflect.Field;
class Test
{
private String s;
public Test()
{
s = "Java Testing Methods";
}
public void method1()
{
System.out.println("The string is " + s);
}
public void method2(int n)
{
System.out.println("The number is " + n);
}
private void method3()
{
System.out.println("Private method invoked");
}
}
class Reflect
{
public static void main(String args[]) throws Exception
{
Test obj = new Test();
Class cls = obj.getClass();
System.out.println("The name of class is " +
cls.getName());
System.out.println("The public methods of class are : ");
Method[] methods = cls.getMethods();
for (Method method:methods)
System.out.println(method.getName());
Method methodcall1 = cls.getDeclaredMethod("method2",
int.class);
methodcall1.invoke(obj, 19);
Field field = cls.getDeclaredField("s");
field.setAccessible(true);
field.set(obj, "JAVA");
Method methodcall2 = cls.getDeclaredMethod("method1");
methodcall2.invoke(obj);
Method methodcall3 = cls.getDeclaredMethod("method3");
methodcall3.setAccessible(true);
methodcall3.invoke(obj);
}
}

Sortie :

Dans le programme Java ci-dessus, nous devons d'abord importer des packages java.lang puis créer un champ privé dans la classe, le constructeur a également créé. La méthode1() a été considérée comme une méthode publique sans argument, puis créée méthode2() également une méthode publique mais avec des arguments entiers et une méthode privée, la méthode3 a été révoquée et les trois méthodes ci-dessus appelées dans la classe Reflect et le résultat est donné ci-dessus capture d'écran.

Conclusion

Dans cet article, nous concluons qu'il ne faut pas tester directement les méthodes privées, mais uniquement leurs effets sur les méthodes publiques qui les appellent. De plus, nous concluons que le test ne doit accéder qu’à l’interface publique de la classe. Si nous testons des méthodes privées, organisons le code réfléchissant dans la classe statique privée.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!