Wie testet man private Methoden in der Einheit?

Question

Ich baue eine Klassenbibliothek, die einige öffentliche und private Methoden haben wird. Ich möchte in der Lage sein, die privaten Methoden zu testen (vor allem während der Entwicklung, aber auch es könnte für zukünftige Refactoring nützlich sein).

Wie geht man dabei richtig vor?

Answer 1

Ich denke, dass man sich eine grundsätzlichere Frage stellen sollte: Warum versuchen Sie überhaupt, die private Methode zu testen? Es riecht nach Code, dass Sie versuchen, die private Methode über die öffentliche Schnittstelle der Klasse zu testen, obwohl diese Methode nicht ohne Grund privat ist, da es sich um ein Implementierungsdetail handelt. Man sollte sich nur mit dem Verhalten der öffentlichen Schnittstelle befassen und nicht damit, wie sie im Verborgenen implementiert ist.

Wenn ich das Verhalten der privaten Methode testen möchte, kann ich ihren Code mit Hilfe gängiger Refactorings in eine andere Klasse extrahieren (vielleicht mit Sichtbarkeit auf Paketebene, um sicherzustellen, dass sie nicht Teil einer öffentlichen API ist). Dann kann ich ihr Verhalten isoliert testen.

Das Produkt des Refactorings bedeutet, dass die private Methode nun eine separate Klasse ist, die ein Kollaborateur der ursprünglichen Klasse geworden ist. Ihr Verhalten wird durch ihre eigenen Unit-Tests gut verstanden werden.

Beim Testen der Originalklasse kann ich dann ihr Verhalten nachahmen, so dass ich mich auf das Testen des Verhaltens der öffentlichen Schnittstelle dieser Klasse konzentrieren kann, anstatt eine kombinatorische Explosion der öffentlichen Schnittstelle und des Verhaltens aller privaten Methoden testen zu müssen.

Ich sehe das ähnlich wie beim Autofahren. Wenn ich ein Auto fahre, dann fahre ich nicht mit offener Motorhaube, damit ich sehen kann, dass der Motor funktioniert. Ich verlasse mich auf die Schnittstelle, die das Auto bietet, nämlich den Drehzahlmesser und den Tachometer, um zu wissen, dass der Motor läuft. Ich verlasse mich darauf, dass sich das Auto tatsächlich bewegt, wenn ich das Gaspedal betätige. Wenn ich den Motor testen will, kann ich das auch isoliert tun :D

Natürlich kann das direkte Testen privater Methoden ein letzter Ausweg sein, wenn Sie eine Legacy-Anwendung haben, aber ich würde es vorziehen, dass Legacy-Code umstrukturiert wird, um bessere Tests zu ermöglichen. Michael Feathers hat ein großartiges Buch über genau dieses Thema geschrieben. http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052

Answer 2

Private Typen, Interna und private Mitglieder sind aus irgendeinem Grund so, und oft möchte man nicht direkt mit ihnen zu tun haben. Und wenn man das tut, ist die Wahrscheinlichkeit groß, dass man später nicht mehr weiterkommt, weil es keine Garantie dafür gibt, dass die Leute, die diese Assemblies erstellt haben, die privaten/internen Implementierungen als solche behalten.

Aber manchmal, wenn ich einige Hacks/Exploration von kompilierten Assemblies oder Assemblies von Drittanbietern durchführe, habe ich selbst den Wunsch, eine private Klasse oder eine Klasse mit einem privaten oder internen Konstruktor zu initialisieren. Oder manchmal, wenn ich mit vorkompilierten Legacy-Bibliotheken zu tun habe, die ich nicht ändern kann, schreibe ich am Ende einige Tests gegen eine private Methode.

So entstand der AccessPrivateWrapper - http://amazedsaint.blogspot.com/2010/05/accessprivatewrapper-c-40-dynamic.html - ist eine schnelle Wrapper-Klasse, die die Arbeit mit den dynamischen Funktionen von C# 4.0 und Reflection erleichtert.

Sie können interne/private Typen erstellen wie

    //Note that the wrapper is dynamic
    dynamic wrapper = AccessPrivateWrapper.FromType
        (typeof(SomeKnownClass).Assembly,"ClassWithPrivateConstructor");

    //Access the private members
    wrapper.PrivateMethodInPrivateClass();

Answer 3

Nun, Sie können private Methoden auf zwei Arten testen

1. können Sie eine Instanz von PrivateObject Klasse lautet die Syntax wie folgt

   PrivateObject obj= new PrivateObject(PrivateClass);
   //now with this obj you can call the private method of PrivateCalss.
   obj.PrivateMethod("Parameters");

2. Sie können die Reflexion nutzen.

   PrivateClass obj = new PrivateClass(); // Class containing private obj
   Type t = typeof(PrivateClass); 
   var x = t.InvokeMember("PrivateFunc", 
       BindingFlags.InvokeMethod | BindingFlags.NonPublic | BindingFlags.Public |  
           BindingFlags.Instance, null, obj, new object[] { 5 });

Answer 4

Ich habe auch die Methode InternalsVisibleToAttribute verwendet. Es ist auch erwähnenswert, dass, wenn Sie sich unwohl dabei fühlen, Ihre zuvor privaten Methoden intern zu machen, um dies zu erreichen, dann sollten sie vielleicht sowieso nicht Gegenstand direkter Unit-Tests sein.

Schließlich testen Sie die Verhalten Ihrer Klasse und nicht deren spezifische Umsetzung - können Sie letzteres ändern, ohne das erstere zu ändern, und Ihre Tests sollten trotzdem bestehen.

Answer 5

Es gibt 2 Arten von privaten Methoden. Statische private Methoden und nicht statische private Methoden (Instanzmethoden). Die folgenden 2 Artikel erklären, wie man private Methoden mit Beispielen testet.

1. Unit Testing Statische private Methoden
2. Unit Testing nicht statischer privater Methoden