Wie teste ich eine private Funktion oder eine Klasse mit privaten Methoden, Feldern oder inneren Klassen?

Wie teste ich eine Klasse (mit xUnit) mit internen privaten Methoden, Feldern oder verschachtelten Klassen? Oder eine Funktion, die durch interne Verknüpfung ( staticin C / C ++) privat gemacht wird oder sich in einem privaten ( anonymen ) Namespace befindet?

Es scheint schlecht, den Zugriffsmodifikator für eine Methode oder Funktion zu ändern, um einen Test ausführen zu können.

Aktualisieren:

Etwa 10 Jahre später ist der beste Weg, eine private Methode oder ein unzugängliches Mitglied zu testen, @Jailbreakdas Manifold- Framework.

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

Auf diese Weise bleibt Ihr Code typsicher und lesbar. Keine Designkompromisse, keine Überbelichtung von Methoden und Feldern für Tests.

Wenn Sie eine ältere Java- Anwendung haben und die Sichtbarkeit Ihrer Methoden nicht ändern dürfen, können Sie private Methoden am besten mit Reflection testen .

Intern verwenden wir Helfer, um / set privateund private staticVariablen sowie Aufrufe privateund private staticMethoden abzurufen . Mit den folgenden Mustern können Sie so ziemlich alles tun, was mit den privaten Methoden und Feldern zu tun hat. Natürlich können Sie private static finalVariablen nicht durch Reflexion ändern .

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

Und für Felder:

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

Hinweise:
1. Hier TargetClass.getDeclaredMethod(methodName, argClasses)können Sie privateMethoden untersuchen. Gleiches gilt für getDeclaredField.
2. Das setAccessible(true)ist erforderlich, um mit Privaten herumzuspielen.

Der beste Weg, eine private Methode zu testen, ist eine andere öffentliche Methode. Wenn dies nicht möglich ist, ist eine der folgenden Bedingungen erfüllt:

1. Die private Methode ist toter Code
2. In der Nähe der Klasse, die Sie testen, riecht es nach Design
3. Die Methode, die Sie testen möchten, sollte nicht privat sein

Wenn ich private Methoden in einer Klasse habe, die so kompliziert sind, dass ich die privaten Methoden direkt testen muss, ist das ein Codegeruch: Meine Klasse ist zu kompliziert.

Mein üblicher Ansatz, um solche Probleme anzugehen, besteht darin, eine neue Klasse herauszuarbeiten, die die interessanten Teile enthält. Oft können diese Methode und die Felder, mit denen sie interagiert, und möglicherweise eine oder zwei andere Methoden in eine neue Klasse extrahiert werden.

Die neue Klasse macht diese Methoden als "öffentlich" verfügbar, sodass sie für Unit-Tests zugänglich sind. Die neuen und alten Klassen sind jetzt beide einfacher als die ursprüngliche Klasse, was für mich großartig ist (ich muss die Dinge einfach halten, sonst verliere ich mich!).

Beachten Sie, dass ich nicht vorschlage, dass Leute Klassen erstellen, ohne ihr Gehirn zu benutzen! Hier geht es darum, die Kräfte des Komponententests zu nutzen, um gute neue Klassen zu finden.

Ich habe in der Vergangenheit Reflexion verwendet , um dies für Java zu tun, und meiner Meinung nach war es ein großer Fehler.

Genau genommen sollten Sie keine Komponententests schreiben, die private Methoden direkt testen. Was Sie testen sollten , ist der öffentliche Vertrag, den die Klasse mit anderen Objekten hat. Sie sollten niemals die Interna eines Objekts direkt testen. Wenn ein anderer Entwickler eine kleine interne Änderung an der Klasse vornehmen möchte, die sich nicht auf den öffentlichen Vertrag der Klasse auswirkt, muss er Ihren reflexionsbasierten Test ändern, um sicherzustellen, dass er funktioniert. Wenn Sie dies während eines Projekts wiederholt tun, stellen Unit-Tests keine nützliche Messung des Codezustands mehr dar und werden zu einem Hindernis für die Entwicklung und zu einem Ärger für das Entwicklungsteam.

Ich empfehle stattdessen, ein Tool zur Codeabdeckung wie Cobertura zu verwenden, um sicherzustellen, dass die von Ihnen geschriebenen Komponententests eine angemessene Abdeckung des Codes in privaten Methoden bieten. Auf diese Weise testen Sie indirekt, was die privaten Methoden tun, und behalten ein höheres Maß an Agilität bei.

In diesem Artikel: Testen privater Methoden mit JUnit und SuiteRunner (Bill Venners) haben Sie grundsätzlich 4 Optionen:

1. Testen Sie keine privaten Methoden.
2. Geben Sie dem Methodenpaket Zugriff.
3. Verwenden Sie eine verschachtelte Testklasse.
4. Verwenden Sie Reflexion.

Im Allgemeinen soll ein Komponententest die öffentliche Schnittstelle einer Klasse oder Einheit ausüben. Private Methoden sind daher Implementierungsdetails, die Sie nicht explizit testen würden.

Nur zwei Beispiele, wo ich eine private Methode testen möchte:

1. Entschlüsselungsroutinen - Ich möchte sie nicht für jedermann sichtbar machen, um sie nur zum Testen zu sehen, sonst kann jeder sie zum Entschlüsseln verwenden. Sie sind jedoch dem Code eigen, kompliziert und müssen immer funktionieren (die offensichtliche Ausnahme ist die Reflexion, mit der in den meisten Fällen sogar private Methoden angezeigt werden können, wenn dies SecurityManagernicht konfiguriert ist, um dies zu verhindern).
2. Erstellen eines SDK für den Community-Verbrauch. Hier hat die Öffentlichkeit eine ganz andere Bedeutung, da dies Code ist, den die ganze Welt sehen kann (nicht nur innerhalb meiner Anwendung). Ich setze Code in private Methoden ein, wenn ich nicht möchte, dass die SDK-Benutzer ihn sehen. Ich sehe dies nicht als Codegeruch, sondern nur als Funktionsweise der SDK-Programmierung. Aber natürlich muss ich meine privaten Methoden noch testen, und dort lebt die Funktionalität meines SDK tatsächlich.

Ich verstehe die Idee, nur den "Vertrag" zu testen. Aber ich sehe nicht, dass man befürworten kann, Code nicht zu testen - Ihr Kilometerstand kann variieren.

Mein Kompromiss besteht also darin, die JUnits durch Reflexion zu komplizieren, anstatt meine Sicherheit und mein SDK zu gefährden.

Die privaten Methoden werden von einer öffentlichen Methode aufgerufen, daher sollten die Eingaben in Ihre öffentlichen Methoden auch private Methoden testen, die von diesen öffentlichen Methoden aufgerufen werden. Wenn eine öffentliche Methode fehlschlägt, kann dies ein Fehler in der privaten Methode sein.

Ein anderer Ansatz, den ich verwendet habe, besteht darin, eine private Methode so zu ändern, dass sie privat oder geschützt verpackt wird, und sie dann mit der Annotation @VisibleForTesting der Google Guava-Bibliothek zu ergänzen .

Dies weist jeden, der diese Methode verwendet, an, Vorsicht walten zu lassen und nicht einmal in einem Paket direkt darauf zuzugreifen. Auch eine Testklasse muss nicht in demselben Paket sein physisch , aber im selben Paket unter dem Testordner.

Befindet sich beispielsweise eine zu testende Methode, sollte src/main/java/mypackage/MyClass.javaIhr Testaufruf in platziert werden src/test/java/mypackage/MyClassTest.java. Auf diese Weise haben Sie Zugriff auf die Testmethode in Ihrer Testklasse.

Um Test Legacy - Code mit großen und schrulligen Klassen, ist es oft sehr hilfreich, wenn die eine Privat zu testen (oder öffentlich) Methode Ich schreibe jetzt .

Ich benutze das junitx.util.PrivateAccessor-Paket für Java. Viele hilfreiche Einzeiler für den Zugriff auf private Methoden und private Felder.

import junitx.util.PrivateAccessor;

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

Im Spring Framework können Sie private Methoden mit folgender Methode testen:

ReflectionTestUtils.invokeMethod()

Zum Beispiel:

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

Nachdem ich die Lösung von Cem Catikkas mit Reflection für Java ausprobiert habe , muss ich sagen, dass seine Lösung eleganter war als hier beschrieben. Wenn Sie jedoch nach einer Alternative zur Verwendung von Reflection suchen und Zugriff auf die zu testende Quelle haben, ist dies weiterhin eine Option.

Es ist möglich, private Methoden einer Klasse zu testen , insbesondere bei testgetriebener Entwicklung , bei der Sie kleine Tests entwerfen möchten, bevor Sie Code schreiben.

Durch das Erstellen eines Tests mit Zugriff auf private Mitglieder und Methoden können Codebereiche getestet werden, auf die nur schwer zugegriffen werden kann, wenn nur auf öffentliche Methoden zugegriffen wird. Wenn eine öffentliche Methode mehrere Schritte umfasst, kann sie aus mehreren privaten Methoden bestehen, die dann einzeln getestet werden können.

Vorteile:

• Kann auf eine feinere Granularität getestet werden

Nachteile:

• Der Testcode muss sich in derselben Datei wie der Quellcode befinden, was möglicherweise schwieriger zu warten ist
• Ähnlich wie bei Ausgabedateien der Klasse müssen sie im selben Paket verbleiben, wie im Quellcode deklariert

Wenn kontinuierliche Tests diese Methode erfordern, kann dies ein Signal dafür sein, dass die privaten Methoden extrahiert werden sollten, die auf herkömmliche öffentliche Weise getestet werden könnten.

Hier ist ein kompliziertes Beispiel dafür, wie dies funktionieren würde:

// 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);
        }
    }
}

Die innere Klasse würde zusammengestellt werden ClassToTest$StaticInnerTest.

Siehe auch: Java-Tipp 106: Statische innere Klassen für Spaß und Gewinn

Wie andere gesagt haben ... testen Sie private Methoden nicht direkt. Hier einige Gedanken:

1. Halten Sie alle Methoden klein und konzentriert (leicht zu testen, leicht zu finden, was falsch ist)
2. Verwenden Sie Tools zur Codeabdeckung. Ich mag Cobertura (oh glücklicher Tag, sieht aus wie eine neue Version heraus ist!)

Führen Sie die Codeabdeckung für die Komponententests aus. Wenn Sie feststellen, dass die Methoden nicht vollständig getestet wurden, fügen Sie sie zu den Tests hinzu, um die Abdeckung zu verbessern. Streben Sie eine 100% ige Codeabdeckung an, aber stellen Sie fest, dass Sie diese wahrscheinlich nicht erhalten werden.

Private Methoden werden von öffentlichen genutzt. Ansonsten sind sie toter Code. Aus diesem Grund testen Sie die öffentliche Methode, indem Sie die erwarteten Ergebnisse der öffentlichen Methode und damit die von ihr verwendeten privaten Methoden bestätigen.

Das Testen privater Methoden sollte durch Debuggen getestet werden, bevor Sie Ihre Komponententests mit öffentlichen Methoden ausführen.

Sie können auch mithilfe einer testgetriebenen Entwicklung debuggt werden, indem Sie Ihre Komponententests debuggen, bis alle Ihre Aussagen erfüllt sind.

Ich persönlich glaube, es ist besser, Klassen mit TDD zu erstellen. Erstellen Sie die öffentlichen Methodenstubs und generieren Sie dann Komponententests mit allen im Voraus definierten Zusicherungen, damit das erwartete Ergebnis der Methode ermittelt wird, bevor Sie sie codieren. Auf diese Weise gehen Sie nicht den falschen Weg, um die Aussagen zum Komponententest an die Ergebnisse anzupassen. Ihre Klasse ist dann robust und erfüllt die Anforderungen, wenn alle Ihre Unit-Tests bestanden sind.

Wenn Sie Spring verwenden, bietet ReflectionTestUtils einige nützliche Tools, die hier mit minimalem Aufwand helfen. Zum Beispiel, um ein Mock für ein privates Mitglied einzurichten, ohne gezwungen zu sein, einen unerwünschten öffentlichen Setter hinzuzufügen:

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

Wenn Sie versuchen, vorhandenen Code zu testen, den Sie nur ungern oder nicht ändern können, ist Reflection eine gute Wahl.

Wenn das Design der Klasse noch flexibel ist und Sie eine komplizierte private Methode haben, die Sie separat testen möchten, empfehlen wir Ihnen, sie in eine separate Klasse zu ziehen und diese Klasse separat zu testen. Dies muss die öffentliche Schnittstelle der ursprünglichen Klasse nicht ändern. Es kann intern eine Instanz der Hilfsklasse erstellen und die Hilfsmethode aufrufen.

Wenn Sie schwierige Fehlerbedingungen testen möchten, die von der Hilfsmethode herrühren, können Sie noch einen Schritt weiter gehen. Extrahieren Sie eine Schnittstelle aus der Hilfsklasse, fügen Sie der ursprünglichen Klasse einen öffentlichen Getter und Setter hinzu, um die Hilfsklasse (die über ihre Schnittstelle verwendet wird) einzufügen, und fügen Sie dann eine Scheinversion der Hilfsklasse in die ursprüngliche Klasse ein, um zu testen, wie die ursprüngliche Klasse funktioniert reagiert auf Ausnahmen vom Helfer. Dieser Ansatz ist auch hilfreich, wenn Sie die ursprüngliche Klasse testen möchten, ohne auch die Hilfsklasse zu testen.

Durch das Testen privater Methoden wird die Kapselung Ihrer Klasse unterbrochen, da bei jeder Änderung der internen Implementierung der Clientcode (in diesem Fall die Tests) unterbrochen wird.

Testen Sie also keine privaten Methoden.

Die Antwort von der FAQ-Seite von JUnit.org :

Aber wenn Sie müssen ...

Wenn Sie JDK 1.3 oder höher verwenden, können Sie mithilfe von Reflection den Zugriffssteuerungsmechanismus mithilfe des PrivilegedAccessor untergraben . Weitere Informationen zur Verwendung finden Sie in diesem Artikel .

Wenn Sie JDK 1.6 oder höher verwenden und Ihre Tests mit @Test kommentieren, können Sie Dp4j verwenden , um Reflexion in Ihre Testmethoden einzufügen . Einzelheiten zur Verwendung finden Sie in diesem Testskript .

PS Ich bin der Hauptverantwortliche für Dp4j . Frag mich, ob du Hilfe brauchst. :) :)

Wenn Sie private Methoden einer Legacy-Anwendung testen möchten, bei denen Sie den Code nicht ändern können, ist eine Option für Java jMockit , mit der Sie Mocks für ein Objekt erstellen können, auch wenn diese für die Klasse privat sind.

Ich neige dazu, private Methoden nicht zu testen. Da liegt der Wahnsinn. Persönlich glaube ich, dass Sie nur Ihre öffentlich zugänglichen Schnittstellen testen sollten (und das schließt geschützte und interne Methoden ein).

Wenn Sie JUnit verwenden, schauen Sie sich Junit-Addons an . Es kann das Java-Sicherheitsmodell ignorieren und auf private Methoden und Attribute zugreifen.

Ich würde vorschlagen, dass Sie Ihren Code ein wenig umgestalten. Wenn Sie darüber nachdenken müssen, Reflektion oder andere Dinge zu verwenden, um nur Ihren Code zu testen, läuft etwas mit Ihrem Code nicht.

Sie haben verschiedene Arten von Problemen erwähnt. Beginnen wir mit privaten Feldern. Bei privaten Feldern hätte ich einen neuen Konstruktor hinzugefügt und Felder eingefügt. An Stelle von:

public class ClassToTest {

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

Ich hätte das benutzt:

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;
    }
    ...
}

Dies ist auch mit altem Code kein Problem. Alter Code verwendet einen leeren Konstruktor, und wenn Sie mich fragen, sieht überarbeiteter Code sauberer aus, und Sie können die erforderlichen Werte ohne Reflexion in den Test einfügen.

Nun zu privaten Methoden. Nach meiner persönlichen Erfahrung hat diese Methode in dieser Klasse nichts zu tun, wenn Sie eine private Methode zum Testen stubben müssen. In diesem Fall besteht ein gängiges Muster darin, es in eine Schnittstelle zu verpacken , Callableund dann übergeben Sie diese Schnittstelle auch im Konstruktor (mit diesem Trick mit mehreren Konstruktoren):

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

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

Meistens sieht alles, was ich geschrieben habe, so aus, als wäre es ein Abhängigkeitsinjektionsmuster. Nach meiner persönlichen Erfahrung ist es beim Testen sehr nützlich, und ich denke, dass diese Art von Code sauberer und einfacher zu warten ist. Ich würde dasselbe über verschachtelte Klassen sagen. Wenn eine verschachtelte Klasse eine umfangreiche Logik enthält, ist es besser, wenn Sie sie als private Paketklasse verschoben und in eine Klasse eingefügt haben, die sie benötigt.

Es gibt auch einige andere Entwurfsmuster, die ich beim Umgestalten und Verwalten von Legacy-Code verwendet habe, aber alles hängt von den Fällen ab, in denen Ihr Code getestet werden soll. Die Verwendung von Reflection ist meistens kein Problem, aber wenn Sie eine Unternehmensanwendung haben, die stark getestet wird und Tests vor jeder Bereitstellung ausgeführt werden, wird alles sehr langsam (es ist nur ärgerlich und ich mag solche Dinge nicht).

Es gibt auch eine Setter-Injektion, aber ich würde nicht empfehlen, sie zu verwenden. Ich bleibe lieber bei einem Konstruktor und initialisiere alles, wenn es wirklich notwendig ist, und lasse die Möglichkeit, notwendige Abhängigkeiten einzufügen.

Auf eine private Methode darf nur innerhalb derselben Klasse zugegriffen werden. Es gibt also keine Möglichkeit, eine "private" Methode einer Zielklasse aus einer Testklasse heraus zu testen. Ein Ausweg ist, dass Sie Unit-Tests manuell durchführen oder Ihre Methode von "privat" in "geschützt" ändern können.

Und dann kann auf eine geschützte Methode nur innerhalb desselben Pakets zugegriffen werden, in dem die Klasse definiert ist. Wenn Sie also eine geschützte Methode einer Zielklasse testen, müssen Sie Ihre Testklasse im selben Paket wie die Zielklasse definieren.

Wenn all das nicht Ihren Anforderungen entspricht, verwenden Sie die Reflektionsmethode, um auf die private Methode zuzugreifen.

Wie viele oben vorgeschlagen haben, besteht eine gute Möglichkeit darin, sie über Ihre öffentlichen Schnittstellen zu testen.

Wenn Sie dies tun, ist es eine gute Idee, ein Tool zur Codeabdeckung (wie Emma) zu verwenden, um festzustellen, ob Ihre privaten Methoden tatsächlich aus Ihren Tests ausgeführt werden.

Hier ist meine generische Funktion zum Testen privater Felder:

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);
}

Ein Beispiel finden Sie weiter unten.

Die folgende Importanweisung sollte hinzugefügt werden:

import org.powermock.reflect.Whitebox;

Jetzt können Sie das Objekt mit der privaten Methode, dem aufzurufenden Methodennamen und den folgenden zusätzlichen Parametern direkt übergeben.

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

Heute habe ich eine Java-Bibliothek gepusht, um beim Testen privater Methoden und Felder zu helfen. Es wurde speziell für Android entwickelt, kann aber wirklich für jedes Java-Projekt verwendet werden.

Wenn Sie Code mit privaten Methoden oder Feldern oder Konstruktoren haben, können Sie BoundBox verwenden . Es macht genau das, wonach Sie suchen. Hier ist ein Beispiel für einen Test, der auf zwei private Felder einer Android-Aktivität zugreift, um sie zu testen:

@UiThreadTest
public void testCompute() {

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

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

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

BoundBox erleichtert das Testen von privaten / geschützten Feldern, Methoden und Konstruktoren. Sie können sogar auf Dinge zugreifen, die durch Vererbung verborgen sind. In der Tat unterbricht BoundBox die Kapselung. Sie erhalten Zugriff auf all das durch Reflexion, ABER alles wird zur Kompilierungszeit überprüft.

Es ist ideal zum Testen von Legacy-Code. Verwenden Sie es vorsichtig. ;)

https://github.com/stephanenicolas/boundbox

Zuerst werde ich diese Frage wegwerfen: Warum brauchen Ihre privaten Mitglieder isolierte Tests? Sind sie so komplex und bieten so komplizierte Verhaltensweisen, dass neben der öffentlichen Oberfläche auch Tests erforderlich sind? Es handelt sich um Unit-Tests, nicht um Code-Code-Tests. Schwitzen Sie nicht die kleinen Sachen.

Wenn sie so groß sind, dass diese privaten Mitglieder jeweils eine komplexe Einheit bilden, sollten Sie erwägen, solche privaten Mitglieder aus dieser Klasse heraus zu überarbeiten.

Wenn Refactoring unangemessen oder nicht durchführbar ist, können Sie das Strategiemuster verwenden, um den Zugriff auf diese privaten Mitgliedsfunktionen / Mitgliedsklassen im Unit-Test zu ersetzen? Im Unit-Test würde die Strategie eine zusätzliche Validierung bieten, in Release-Builds wäre dies jedoch ein einfaches Passthrough.

Ich hatte kürzlich dieses Problem und schrieb ein kleines Tool namens Picklock , das die Probleme der expliziten Verwendung der Java Reflection API vermeidet. Zwei Beispiele:

Aufrufmethoden, zB private void method(String s)- durch Java-Reflektion

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

private void method(String s)Aufrufmethoden , zB - von Picklock

interface Accessible {
  void method(String s);
}

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

Einstellen von Feldern, zB private BigInteger amount;- durch Java-Reflexion

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

Einstellen von Feldern, zB private BigInteger amount;- durch Picklock

interface Accessible {
  void setAmount(BigInteger amount);
}

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

PowerMockito ist dafür gemacht. Verwenden Sie die Maven-Abhängigkeit

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

Dann können Sie tun

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