Wie teste ich eine private Funktion oder eine Klasse, die über private Methoden, Felder oder innere Klassen verfügt?

Question

Wie teste ich (mit xUnit) eine Klasse, die über interne private Methoden, Felder oder verschachtelte Klassen verfügt?Oder eine Funktion, die durch have privat gemacht wird interne Verknüpfung (static in C/C++) oder befindet sich in einer privaten (anonym) Namensraum?

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

Answer 1

Aktualisieren:

Etwa 10 Jahre später ist vielleicht der beste Weg, eine private Methode oder ein unzugängliches Mitglied zu testen, über @Jailbreak von dem Verteiler Rahmen.

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

So bleibt Ihr Code typsicher und lesbar.Keine Kompromisse beim Design, keine Überbelichtung von Methoden und Feldern für Tests.

Wenn Sie ein gewisses Erbe haben Java Anwendung verwenden und Sie die Sichtbarkeit Ihrer Methoden nicht ändern dürfen, ist die beste Möglichkeit zum Testen privater Methoden die Verwendung von Betrachtung.

Intern verwenden wir Helfer zum Abrufen/Festlegen private Und private static Variablen sowie Aufruf private Und private static Methoden.Mit den folgenden Mustern können Sie so ziemlich alles tun, was mit privaten Methoden und Feldern zu tun hat.Natürlich kann man sich nicht ändern private static final Variablen durch Reflexion.

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

---

Anmerkungen:
1. TargetClass.getDeclaredMethod(methodName, argClasses) lässt Sie hineinschauen private Methoden.Das Gleiche gilt für getDeclaredField.
2.Der setAccessible(true) ist erforderlich, um mit Gefreiten herumzuspielen.

Answer 2

Der beste Weg, eine private Methode zu testen, ist die Verwendung einer anderen öffentlichen Methode.Wenn dies nicht möglich ist, dann 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

Answer 3

Wenn ich private Methoden in einer Klasse habe, die so kompliziert sind, dass ich das Bedürfnis verspüre, die privaten Methoden direkt zu testen, riecht das nach Code:Meine Klasse ist zu kompliziert.

Mein üblicher Ansatz zur Lösung solcher Probleme besteht darin, eine neue Klasse herauszuarbeiten, die die interessanten Teile enthält.Oftmals können diese Methode und die Felder, mit denen sie interagiert, und vielleicht noch eine oder zwei weitere Methoden in eine neue Klasse extrahiert werden.

Die neue Klasse stellt diese Methoden als „öffentlich“ bereit, sodass sie für Unit-Tests zugänglich sind.Die neue und die alte Klasse 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 den Überblick!).

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

Answer 4

Ich habe benutzt Betrachtung Ich habe es in der Vergangenheit nicht geschafft, dies für Java zu tun, und meiner Meinung nach war das ein großer Fehler.

Streng genommen sollten Sie das tun nicht Schreiben Sie Unit-Tests, die private Methoden direkt testen.Was du sollen Be Testing ist der öffentliche Vertrag, den die Klasse mit anderen Objekten hat.Sie sollten die Interna eines Objekts niemals 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/sie dann Ihren reflexionsbasierten Test ändern, um sicherzustellen, dass er funktioniert.Wenn Sie dies während eines Projekts wiederholt tun, sind Unit-Tests kein nützliches Maß für den Zustand des Codes mehr, sondern werden zu einem Hindernis für die Entwicklung und zu einem Ärgernis für das Entwicklungsteam.

Stattdessen empfehle ich die Verwendung eines Code-Coverage-Tools wie Cobertura, um sicherzustellen, dass die von Ihnen geschriebenen Unit-Tests eine angemessene Abdeckung des Codes in privaten Methoden bieten.Auf diese Weise testen Sie indirekt, was die privaten Methoden bewirken, und sorgen für ein höheres Maß an Agilität.

Answer 5

Aus diesem Artikel: Testen privater Methoden mit JUnit und SuiteRunner (Bill Venners), Sie haben grundsätzlich 4 Möglichkeiten:

• Testen Sie keine privaten Methoden.
• Gewähren Sie dem Methodenpaket Zugriff.
• Verwenden Sie eine verschachtelte Testklasse.
• Nutzen Sie Reflexion.

Answer 6

Im Allgemeinen dient ein Komponententest dazu, die öffentliche Schnittstelle einer Klasse oder Einheit zu testen.Daher handelt es sich bei privaten Methoden um Implementierungsdetails, von denen Sie nicht erwarten würden, dass sie explizit getestet werden.

Answer 7

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

1. Entschlüsselungsroutinen - Ich möchte sie für niemanden sichtbar machen, um nur zum Testen zu sehen, sonst kann jeder sie zum Entschlüsseln verwenden.Sie sind jedoch dem Code, kompliziert und müssen immer arbeiten (die offensichtliche Ausnahme ist die Reflexion, mit der selbst private Methoden in den meisten Fällen angezeigt werden können, wenn SecurityManager ist nicht so konfiguriert, dass dies verhindert wird).
2. Erstellen eines SDK Für den Verbrauch der Gemeinschaft.Hier nimmt die Öffentlichkeit eine ganz andere Bedeutung an, da dies Code ist, den die ganze Welt sehen kann (nicht nur intern für meine Bewerbung).Ich stelle Code in private Methoden ein, wenn ich nicht möchte, dass die SDK -Benutzer ihn sehen - ich sehe dies nicht als Codegeruch, nur als wie SDK -Programmierung funktioniert.Aber natürlich muss ich meine privaten Methoden noch testen, und sie leben tatsächlich die Funktionalität meines SDK.

Ich verstehe die Idee, nur den „Vertrag“ zu testen.Aber ich sehe nicht, dass man dafür plädieren kann, Code tatsächlich nicht zu testen – Ihr Erfolg kann variieren.

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

Answer 8

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, liegt möglicherweise ein Fehler in der privaten Methode vor.

Answer 9

Ein anderer Ansatz, den ich verwendet habe, besteht darin, eine private Methode in „package private“ oder „protected“ zu ändern und sie dann mit der zu ergänzen @VisibleForTesting Anmerkung der Google Guava-Bibliothek.

Dadurch wird jeder, der diese Methode verwendet, darauf hingewiesen, vorsichtig zu sein und nicht direkt darauf zuzugreifen, auch nicht in einem Paket.Außerdem muss sich eine Testklasse nicht im selben Paket befinden physisch, aber im gleichen Paket unter der prüfen Ordner.

Zum Beispiel, wenn eine zu testende Methode in ist src/main/java/mypackage/MyClass.java Dann sollte Ihr Testanruf getätigt werden src/test/java/mypackage/MyClassTest.java.Auf diese Weise erhalten Sie Zugriff auf die Testmethode in Ihrer Testklasse.

Answer 10

Um Legacy-Code mit großen und eigenartigen Klassen zu testen, ist es oft sehr hilfreich, die eine private (oder öffentliche) Methode testen zu können, die ich schreibe im Augenblick.

Ich verwende 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);

Answer 11

Nachdem ich Cem Catikkas‘ ausprobiert habe Lösung mittels Reflexion Für Java muss ich sagen, dass es eine elegantere Lösung war, als ich hier beschrieben habe.Wenn Sie jedoch nach einer Alternative zur Verwendung von Reflektion suchen und Zugriff auf die Quelle haben, die Sie testen, ist dies immer noch eine Option.

Es kann sinnvoll sein, private Methoden einer Klasse zu testen, insbesondere mit testgetriebene Entwicklung, wo 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, die mit Zugriff nur auf öffentliche Methoden schwer gezielt anzusprechen sind.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 Quellcode befinden, was schwieriger zu verwalten ist
• Ebenso müssen .class-Ausgabedateien innerhalb desselben Pakets bleiben, wie im Quellcode deklariert

Wenn jedoch 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 das 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 kompiliert werden ClassToTest$StaticInnerTest.

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

Answer 12

Wie andere schon gesagt haben...Testen Sie private Methoden nicht direkt.Hier ein paar Gedanken:

1. Halten Sie alle Methoden klein und fokussiert (einfach zu testen, leicht zu finden, was falsch ist)
2. Verwenden Sie Tools zur Codeabdeckung.Ich mag Cobertura (Oh, schönen Tag, es sieht so aus, als ob eine neue Version draußen ist!)

Führen Sie die Codeabdeckung für die Komponententests aus.Wenn Sie feststellen, dass Methoden nicht vollständig getestet wurden, ergänzen Sie die Tests, um die Abdeckung zu erhöhen.Streben Sie eine 100-prozentige Codeabdeckung an, aber seien Sie sich darüber im Klaren, dass Sie diese wahrscheinlich nicht erreichen werden.

Answer 13

Private Methoden werden von öffentlichen genutzt.Ansonsten handelt es sich um toten Code.Aus diesem Grund testen Sie die öffentliche Methode und bestätigen die erwarteten Ergebnisse der öffentlichen Methode und damit die privaten Methoden, die sie nutzt.

Das Testen privater Methoden sollte durch Debuggen getestet werden, bevor Sie Ihre Komponententests für öffentliche Methoden ausführen.

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

Ich persönlich glaube, dass es besser ist, Klassen mit TDD zu erstellen;Erstellen der öffentlichen Methoden-Stubs und anschließendes Generieren von Komponententests mit alle Die im Voraus definierten Behauptungen, sodass das erwartete Ergebnis der Methode bestimmt wird, bevor Sie sie codieren.Auf diese Weise begehen Sie nicht den falschen Weg, die Unit-Test-Behauptungen an die Ergebnisse anzupassen.Ihre Klasse ist dann robust und erfüllt die Anforderungen, wenn alle Ihre Unit-Tests erfolgreich sind.

Answer 14

Im Frühlingsrahmen Sie können private Methoden mit dieser Methode testen:

ReflectionTestUtils.invokeMethod()

Zum Beispiel:

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

Answer 15

Wenn Sie Spring verwenden, ReflectionTestUtils stellt einige praktische Tools bereit, die hier mit minimalem Aufwand Abhilfe schaffen.Um beispielsweise einen Mock auf einem privaten Mitglied einzurichten, ohne gezwungen zu sein, einen unerwünschten öffentlichen Setter hinzuzufügen:

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

Answer 16

Wenn Sie vorhandenen Code testen möchten, 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, empfehle ich Ihnen, sie in eine separate Klasse zu übertragen 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 ausgehen, können Sie noch einen Schritt weiter gehen.Extrahieren Sie eine Schnittstelle aus der Hilfsklasse, fügen Sie der Originalklasse einen öffentlichen Getter und Setter hinzu, um die Hilfsklasse (verwendet über ihre Schnittstelle) einzufügen, und fügen Sie dann eine Scheinversion der Hilfsklasse in die Originalklasse ein, um zu testen, wie die Originalklasse funktioniert reagiert auf Ausnahmen vom Helfer.Dieser Ansatz ist auch hilfreich, wenn Sie die Originalklasse testen möchten, ohne auch die Hilfsklasse zu testen.

Answer 17

Durch das Testen privater Methoden wird die Kapselung Ihrer Klasse unterbrochen, da jedes Mal, wenn Sie die interne Implementierung ändern, der Clientcode (in diesem Fall die Tests) beschädigt wird.

Testen Sie also keine privaten Methoden.

Answer 18

Die Antwort von JUnit.org FAQ-Seite:

Aber wenn es sein muss...

Wenn Sie JDK 1.3 oder höher verwenden, können Sie die Reflexion verwenden, um den Zugangskontrollmechanismus mit Hilfe des PrivilegedAccessor.Einzelheiten zur Verwendung finden Sie unter Dieser Artikel.

Wenn Sie JDK 1.6 oder höher verwenden und Ihre Tests mit @Test kommentieren, können Sie verwenden Dp4j um Ihren Testmethoden Reflexion zu verleihen.Weitere Informationen zum Einsatz finden Sie unter dieses Testskript.

P.S.Ich bin der Hauptverantwortliche dafür Dp4j, fragen Mich Wenn du Hilfe benötigst.:) :)

Answer 19

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

Answer 20

Ich neige dazu, private Methoden nicht zu testen.Da liegt Wahnsinn.Ich persönlich bin der Meinung, dass Sie nur Ihre öffentlich zugänglichen Schnittstellen testen sollten (und dazu gehören auch geschützte und interne Methoden).

Answer 21

Wenn Sie JUnit verwenden, schauen Sie sich an Junit-Addons.Es hat die Möglichkeit, das Java-Sicherheitsmodell zu ignorieren und auf private Methoden und Attribute zuzugreifen.

Answer 22

Auf eine private Methode darf nur innerhalb derselben Klasse zugegriffen werden.Es gibt also keine Möglichkeit, eine „private“ Methode einer Zielklasse von einer beliebigen Testklasse aus zu testen.Ein Ausweg besteht darin, dass Sie Unit-Tests manuell durchführen oder Ihre Methode von „privat“ auf „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 wir also eine geschützte Methode einer Zielklasse testen, müssen wir Ihre Testklasse im selben Paket wie die Zielklasse definieren.

Wenn alle oben genannten Punkte Ihren Anforderungen nicht entsprechen, verwenden Sie der Reflexionsweg um auf die private Methode zuzugreifen.

Answer 23

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

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 dort 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 verwendet:

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

Selbst mit älterem Code stellt dies kein Problem dar.Alter Code verwendet einen leeren Konstruktor, und wenn Sie mich fragen, sieht umgestalteter Code sauberer aus und Sie können die erforderlichen Werte ohne Reflexion in den Test einfügen.

Nun zu privaten Methoden.Meiner persönlichen Erfahrung nach hat eine private Methode zum Testen keinen Einfluss auf die Klasse.Ein gängiges Muster wäre in diesem Fall: wickeln es innerhalb einer Schnittstelle, wie Callable und 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;
}

Im Großen und Ganzen sieht alles, was ich geschrieben habe, so aus, als wäre es ein Abhängigkeitsinjektionsmuster.Meiner persönlichen Erfahrung nach ist es beim Testen sehr nützlich und ich denke, dass diese Art von Code sauberer und einfacher zu warten ist.Dasselbe würde ich auch über verschachtelte Klassen sagen.Wenn eine verschachtelte Klasse umfangreiche Logik enthält, wäre es besser, wenn Sie sie als private Paketklasse verschieben und in eine Klasse einfügen würden, die sie benötigt.

Es gibt auch mehrere andere Entwurfsmuster, die ich bei der Umgestaltung und Pflege von Legacy-Code verwendet habe, aber es hängt alles von den zu testenden Fällen Ihres Codes ab.Meistens ist die Verwendung von Reflection kein Problem, aber wenn Sie eine Unternehmensanwendung haben, die intensiv getestet wird und vor jeder Bereitstellung Tests durchgeführt werden, wird alles sehr langsam (es ist einfach nervig und ich mag so etwas nicht).

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

Answer 24

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

Wenn Sie dies tun, ist es eine gute Idee, ein Code-Coverage-Tool (wie Emma) zu verwenden, um zu sehen, ob Ihre privaten Methoden tatsächlich von Ihren Tests ausgeführt werden.

Answer 25

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

Answer 26

Nachfolgend finden Sie ein Beispiel.

Die folgende Importanweisung sollte hinzugefügt werden:

import org.powermock.reflect.Whitebox;

Jetzt können Sie das Objekt, das die private Methode, den aufzurufenden Methodennamen und zusätzliche Parameter enthält, direkt übergeben (siehe unten).

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

Answer 27

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

Wenn Sie Code mit privaten Methoden, Feldern oder Konstruktoren haben, können Sie diesen verwenden BoundBox.Es macht genau das, was Sie suchen.Nachfolgend finden Sie ein Beispiel für einen Test, der zum Testen auf zwei private Felder einer Android-Aktivität zugreift:

@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 privater/geschützter Felder, Methoden und Konstruktoren.Sie können sogar auf Dinge zugreifen, die durch Vererbung verborgen sind.Tatsächlich durchbricht BoundBox die Kapselung.Es wird Ihnen durch Reflexion Zugang zu all dem verschaffen, ABER Alles wird zur Kompilierzeit überprüft.

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

https://github.com/stephanenicolas/boundbox

Answer 28

Zuerst werfe ich diese Frage weg:Warum benötigen Ihre privaten Mitglieder isolierte Tests?Sind sie so komplex und bieten so komplizierte Verhaltensweisen, dass Tests außerhalb der öffentlichen Oberfläche erforderlich sind?Es handelt sich um Unit-Tests, nicht um „Line-of-Code“-Tests.Machen Sie sich keine Gedanken über Kleinigkeiten.

Wenn sie so groß sind, groß genug, dass diese privaten Mitglieder jeweils eine „Einheit“ mit großer Komplexität darstellen, sollten Sie eine Umgestaltung dieser privaten Mitglieder aus dieser Klasse in Betracht ziehen.

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

Answer 29

Ich hatte kürzlich dieses Problem und habe ein kleines Tool namens geschrieben Dietrich, das die Probleme der expliziten Verwendung der Java Reflection API vermeidet, zwei Beispiele:

Aufrufende Methoden, z.B. private void method(String s) - durch Java-Reflexion

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

Aufrufende Methoden, z.B. private void method(String s) - von Picklock

interface Accessible {
  void method(String s);
}

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

Einstellfelder, z.B. private BigInteger amount; - durch Java-Reflexion

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

Einstellfelder, z.B. private BigInteger amount; - von Picklock

interface Accessible {
  void setAmount(BigInteger amount);
}

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

Answer 30

Für Java würde ich verwenden Betrachtung, da mir die Idee nicht gefällt, den Zugriff auf ein Paket für die deklarierte Methode nur zum Testen zu ändern.Normalerweise teste ich jedoch nur die öffentlichen Methoden, um sicherzustellen, dass auch die privaten Methoden ordnungsgemäß funktionieren.

Sie können Reflection nicht verwenden, um private Methoden von außerhalb der Eigentümerklasse abzurufen. Der private Modifikator wirkt sich auch auf Reflection aus

Das ist nicht wahr.Das können Sie auf jeden Fall, wie in erwähnt Die Antwort von Cem Catikkas.