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

Wenn Sie eine private Methode einem Unit-Test unterziehen wollen, kann etwas falsch sein. Unit-Tests sind (im Allgemeinen) dazu gedacht, die Schnittstelle einer Klasse zu testen, also ihre öffentlichen (und geschützten) Methoden. Sie können natürlich eine Lösung für dieses Problem "hacken" (und sei es nur, indem Sie die Methoden öffentlich machen), aber Sie sollten sich auch Gedanken machen:

1. Wenn die Methode, die Sie testen möchten, es wirklich wert ist, getestet zu werden, kann es sich lohnen, sie in eine eigene Klasse zu verschieben.
2. Fügen Sie den öffentlichen Methoden, die die private Methode aufrufen, weitere Tests hinzu, um die Funktionalität der privaten Methode zu testen. (Wie die Kommentatoren anmerkten, sollten Sie dies nur tun, wenn die Funktionalität dieser privaten Methoden wirklich ein Teil der öffentlichen Schnittstelle ist. Wenn sie tatsächlich Funktionen ausführen, die dem Benutzer (d.h. dem Einheitstest) verborgen bleiben, ist dies wahrscheinlich schlecht).

Answer 2

Wenn Sie .net verwenden, sollten Sie die InternalsVisibleToAttribute .

Answer 3

Es ist vielleicht nicht sinnvoll, private Methoden zu testen. Manchmal rufe ich aber auch gerne private Methoden von Testmethoden aus auf. Meistens, um Code-Duplizierung für die Testdatengenerierung zu vermeiden...

Microsoft bietet hierfür zwei Mechanismen an:

Accessors

• Gehen Sie zum Quellcode der Klassendefinition
• Klicken Sie mit der rechten Maustaste auf den Namen der Klasse
• Wählen Sie "Privaten Accessor erstellen".
• Wählen Sie das Projekt, in dem der Accessor erstellt werden soll => Sie erhalten eine neue Klasse mit dem Namen foo_accessor. Diese Klasse wird beim Kompilieren dynamisch erzeugt und stellt alle Mitglieder öffentlich zur Verfügung.

Allerdings ist der Mechanismus manchmal etwas schwerfällig, wenn es um Änderungen an der Schnittstelle der ursprünglichen Klasse geht. Daher vermeide ich es meistens, dies zu verwenden.

PrivateObject-Klasse Die andere Möglichkeit ist die Verwendung von Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject

// Wrap an already existing instance
PrivateObject accessor = new PrivateObject( objectInstanceToBeWrapped );

// Retrieve a private field
MyReturnType accessiblePrivateField = (MyReturnType) accessor.GetField( "privateFieldName" );

// Call a private method
accessor.Invoke( "PrivateMethodName", new Object[] {/* ... */} );

Answer 4

Ich bin nicht einverstanden mit der Philosophie, dass man nur an der Prüfung der externen Schnittstelle interessiert sein sollte. Das ist ein bisschen so, als würde man sagen, dass eine Autowerkstatt nur testen sollte, ob sich die Räder drehen. Ja, letztendlich bin ich an dem externen Verhalten interessiert, aber ich möchte, dass meine eigenen, privaten, internen Tests etwas spezifischer und zielgerichteter sind. Ja, wenn ich ein Refactoring durchführe, muss ich vielleicht einige der Tests ändern, aber wenn es sich nicht um ein massives Refactoring handelt, muss ich nur einige wenige ändern, und die Tatsache, dass die anderen (unveränderten) internen Tests immer noch funktionieren, ist ein guter Indikator dafür, dass das Refactoring erfolgreich war.

Man kann versuchen, alle internen Fälle nur über die öffentliche Schnittstelle abzudecken, und theoretisch ist es möglich, jede interne Methode (oder zumindest jede, die von Bedeutung ist) vollständig über die öffentliche Schnittstelle zu testen, aber dazu muss man sich möglicherweise auf den Kopf stellen, und die Verbindung zwischen den Testfällen, die über die öffentliche Schnittstelle ausgeführt werden, und dem internen Teil der Lösung, den sie testen sollen, kann schwierig oder unmöglich zu erkennen sein. Gezielte Einzeltests, die garantieren, dass die interne Maschinerie ordnungsgemäß funktioniert, sind die geringfügigen Teständerungen, die mit dem Refactoring einhergehen, auf jeden Fall wert - das ist zumindest meine Erfahrung. Wenn Sie bei jedem Refactoring große Änderungen an Ihren Tests vornehmen müssen, dann macht das vielleicht keinen Sinn, aber in diesem Fall sollten Sie vielleicht Ihr Design komplett überdenken. Ein gutes Design sollte so flexibel sein, dass es die meisten Änderungen ohne große Umgestaltungen zulässt.

Answer 5

In den seltenen Fällen, in denen ich private Funktionen testen wollte, habe ich sie in der Regel so geändert, dass sie stattdessen geschützt sind, und dann eine Unterklasse mit einer öffentlichen Wrapper-Funktion geschrieben.

Die Klasse:

...

protected void APrivateFunction()
{
    ...
}

...

Unterklasse zum Testen:

...

[Test]
public void TestAPrivateFunction()
{
    APrivateFunction();
    //or whatever testing code you want here
}

...