Unit-Test für private/protected Member?

[JasonDX]

Zitat von Mikkey:

Und - ein Unit-Test soll eine Methode testen, das ist in der Regel nicht eine komplexe Funktion, die gerade noch public erreichbar ist.

Nein, ein Unit-Test soll nicht eine einzelne Methode testen. Das Aufrufen von einzelnen Methoden geschieht deshalb, weil diese Methoden das Verhalten der Implementierung definieren. Dieses Verhalten ist, was eigentlich getestet wird.
Es gibt für jede Spezifizierung einer Klasse mehrere korrekte Implementierungen. Ein Unit-Test soll nicht prüfen ob eine bestimmte dieser korrekten Implementierungen verwendet wurde, sondern ob es sich überhaupt um eine korrekte Implementierung handelt, und beschreibt bei falschen Implementierungen, welche Verhaltensanforderung nicht erfüllt wurde.

Zitat von Jens01:

Zitat von JasonDX:

Vllt. nicht mit direktem setzen von Eingangsvariablen, aber man kann auf getestete Methoden zurückgreifen:

Code:

testInstance = TestClass.create('testValue');
testInstance.doSomething('withTestValue');
testInstance.testTargetMethod('anothertestvalue');

entsprechend muss transferToState getestet sein, aber dann sollte das Problem auch lösbar sein.

Sorry, kann ich gerade nicht nachvollziehen, was Du meinst.

Es geht ums Testen von Methoden einer Klasse, die einen bestimmten Zustand beschreibt, und wie man diesen Zustand in einem Unittest erreicht.
Mein Beitrag ging darauf ein, dass das Erreichen dieses Zustandes auch mit Hilfe von bereits getesteten Methoden der Klasse geschehen kann.

Zitat von Dejan Vu:

Zitat von JasonDX:

Es stimmt dass bei steigender Komplexität auch das Testen schwieriger wird.

Eigentlich nicht. Es bleiben -im Idealfall- kleine leicht testbare Klassen. Nur eben viel mehr. Aber das Testen selbst wird nicht komplexer, es dauert nur länger. Wir *machen* nur den Fehler, und lassen große Projekte immer komplexer werden, weil wir hier noch was ranbepseln, dort eine Funktion anflanschen usw.

Da hast du an sich recht, ich hab mich auch weng falsch ausgedrückt. Das, was im Endeffekt schwieriger wird, ist die saubere Zerteilung eines komplexen Problems in kleinere, einfache Teilprobleme.

[Sir Rufo]

Das Testen der private und protected Methoden ist in meinen Augen völliger Unfug. Wie die Klasse intern funktioniert ist sowas von egal, sie muss lediglich nach aussen so reagieren, wie vereinbart und durch die Unit-Tests sichergestellt wird.

Wird die Klasse irgendwann mal umgestaltet (bei gleicher Aussenwirkung) dann fliegt einem sofort der Unit-Test um die Ohren obwohl die Anwendung damit weiterhin zurechtkommt (für die hat sich ja nichts verändert).

Der Unit-Test hat auch immer nur eine bedingte Aussagekraft und ist nicht die Lösung für alle Probleme der Programmierwelt. Sicherheitslücken, Speicherlecks, etc. kann man damit nicht entdecken.

[Dejan Vu]

Delphi-Quellcode:

Procedure TFoo.PublicMethodToTest;
var
  list : TSomeList;

Begin
  list := PrivateLoaderOfTheList();
  for item in list do PrivateModifierOfItem(item);
  PrivateSaveTheList();
End;

Klar, ich kann die Liste von außen übergeben. Klar. Ich kann die Liste auch selbst speichern. Aber -verdammt- so lautet der Auftrag und die Spezifikation. "Die Methode lädt eine Liste, modifiziert die Elemente nach Schema F und speichert sie wieder ab".

Wäre doch viel einfacher, wenn ich den 'PrivateModifierOfTheItem' testen könnte. Das der das für alle Elemente einer Liste macht, sieht ein Blinder mit nem Krückstock (<= Legitimer Pragmatismus). Wenn alle Methoden halbwegs sichbar sind, kann ich die vielleicht sogar mocken und spar mir den Pragmatismus mit einem 5-Zeiler.

Soll ich nun den 'PrivateModifierOfTheItem' in eine extra Klasse auslagern, nur damit man den Testen kann? Ist doch bescheuert und außerdem wären wir dann wieder bei der prozeduralen Programmierung, die eigentlich seit 25 Jahren out ist. Ich glaube, hier ist die Frage des TE berechtigt.

Ich würde diese Methode 'PrivateModifierOfItem' protected machen, einen TestklassenWrapper deklarieren, der die Methode public macht und das dann über den Testwrapper testen. Nicht 100% clean, weil ja der TestWrapper getetstet wird und nicht die Klasse selbst, aber das ist ok.

[JasonDX]

Zitat von Dejan Vu:

Klar, ich kann die Liste von außen übergeben. Klar. Ich kann die Liste auch selbst speichern. Aber -verdammt- so lautet der Auftrag und die Spezifikation. "Die Methode lädt eine Liste, modifiziert die Elemente nach Schema F und speichert sie wieder ab".

Und woher läd die Klasse diese Liste? Diese Quelle abstrahieren (sollte man eh), und schon kann man einen sauberen Test schreiben, der nicht nur eine Methode testet - die nichtmal zwingend existieren muss - sondern die geforderte Funktionalität verifiziert, ohne dass man in die Klasse reingucken muss, oder sonst irgendwelche dreckigen Tricks draufschmeißt. Ist eigentlich gar nicht so schwer

[Stevie]

@Dejan Vu:
Irgendwo wird aber diese Klasse mit der Außenwelt reden, wird Daten bekommen haben und irgendwelche Daten ausgeben. Und darüber kann sehr wohl getestet werden, ob deine Methode, die intern rumwurschtelt, richtig gearbeitet hat. Und dazu muss man keine Interna nur für Unittest Zwecke offen legen.

Nicht umsonst ist Clean Code kein Selbstzweck, sondern u.a. dazu da testbaren Code zu schreiben.

[hoika]

Hallo,

"Die Methode lädt eine Liste, modifiziert die Elemente nach Schema F und speichert sie wieder ab".

OK.
Die Methode lädt eine Liste -> Dateiname wird beim Test übergeben, damit kann der Test eine "Liste" bauen, die er kennt

modifiziert die Elemente nach Schema F -> interessiert hier nicht, es muss eine Public-Methode "ModifiziereNachSchemaF" geben, die ruft der Test auf

und speichert sie wieder ab -> aha, wir haben die Änderung, also lädt der Test die Datei und prüft, ob die Änderung korrekt ist


Alles andere ist bereits gesagt, Tests sind BlackBox-Tests, wie die Klasse das intern macht, hat den Test nicht zu interessieren.

Aber:
Liegt die Test-Klasse in der gleichen Unit, wie die zu testende Klasse,
kommt sie dann nicht an die private's ran (das wäre quasi eine "friend"-Implementation.


Heiko

[Dejan Vu]

Wie ich die Klasse testen würde, muss ich ja keinem erzählen. Und das die Klasse so testbar ist, auch nicht. Der einfachste und den Code am wenigsten verändernde Weg wäre der, die private Methode zu testen. Alles andere würde Mocking bedeuten, oder Refactoring, oder beides. Wenn ich entsprechende Helfe habe: Super, die Load-Methode gemockt, um ein Element zu liefern, die Save-Methode deaktiviert und fertig.

Aber ohne Mocking?

Die Aussage war 'private Methoden müssen nicht getestet werden' und ich habe ein Beispiel gebracht, wo das doch sinnvoll wäre. Es ist ja nicht so, das man jeden Tag seine Klassen so schreiben kann, das man sie super testen kann. Meist ist es so, das man legacy Code hat, und nachträglich Tests erstellen muss, um das Kartenhaus zu stabilisieren. Und das man ausgelieferten Code nicht einfach mal so umschreibt, um ihn testbar zu machen, versteht sich ja von selbst. Modifizierer ändern geht gerade, aber selbst bei einem Refactoring würde ich 2x überlegen, ob ich das mache.

Also: Die Klasse *sieht* so aus und ich kann die Methode, die die Liste erstellt, nicht mocken. Weil ich nichts zum mocken habe, verdammt. Also, was bleibt? Die private Methode testen. Und wie teste ich die? Womit wir wieder beim Thema wären.

Zitat von Stevie:

Und darüber kann sehr wohl getestet werden, ob deine Methode, die intern rumwurschtelt, richtig gearbeitet hat.

Mit Mocking: Ja. Sonst: Nein.

Zitat von hoika:

Die Methode lädt eine Liste -> Dateiname wird beim Test übergeben

Das ist kein Unit-Test, denn es werden Systemgrenzen überwunden. Fällt also weg. Außerdem kommen die Daten im Beispiel von einer Quelle, die man nicht simulieren kann. Blöd. Legacy eben.

Zitat von hoika:

modifiziert die Elemente nach Schema F -> interessiert hier nicht,

Na doch. Du schreibst den Test ja gerade, um die Einhaltung von 'Schema F' zu verifizieren und für die Zukunft zu garantieren.

Nur mal so: Wenn ich testbaren Code schreibe, würde ich eine TItemModifier-Klasse bauen, und diese separat testen. Aber wenn ich diesen Code, so wie er ist, testen müsste, würde ich den 'PrivateModifierOfItem' protected machen, eine Testklasse drumherum bauen und diese testen. Das ändert die Funktionalität garantiert nicht.

Testcode neben dem zu testenden Code ist blöd. Das sollte man nicht machen.

[Stevie]

Haaaalt, stop! Lasst uns bitte nicht vom Thema abdriften sondern uns nochmal vor Augen holen, was die Frage und Ausgangslage im ersten Post war (Markierungen von mir):

Zitat von mh166:

da ich zur Zeit versuche mir (möglichst) sauberen Code beizubringen, wollte ich gern auch Tests für mein Projekt schreiben. Sehr interessant ist dazu übrigens das Video von Nick Hodges Unit Testing in Delphi.

Soweit so gut. Habe also angefangen für meine Klasse einen Test (mit DUnitX) zu schreiben. Nun kam aber recht schnell ein Problem für mich auf: wie teste ich private Methoden? Oder wie prüfe ich den Inhalt von privaten Feldern?

Im Video sagte Nick "Only test the code that you want to work properly" — und naja, irgendwie will ich schon, dass auch private Methoden korrekt funktionieren.

Hier ist nicht die Frage nach Unittests in Legacy Code (da hätte man auch wohl direkt die entsprechende Lektüre empfohlen), sondern Clean Code und Unit Tests.
Und da steht meine Aussage: Clean Code bedeutet testbarer Code, testbarer Code bedeutet in Isolation testbarer Code, in Isolation testbarer Code bedeutet öffentliche API und nix anderes

[JasonDX]

Zitat von Dejan Vu:

Die Aussage war 'private Methoden müssen nicht getestet werden' und ich habe ein Beispiel gebracht, wo das doch sinnvoll wäre.

Die Aussage ist auch falsch - richtig wäre: private Methoden müssen nicht direkt, sondern sollten implizit getestet werden.

Ja, wer einen Haufen Mist als Legacy-Code hat, kann Clean-code-Paradigmen nicht immer folgen - da kann man dann auch nichts anderes machen als den Haufen durch Tests höher stapeln, und sich baldmöglichst um ein Refactoring kümmern.