Unit-Test für private/protected Member?

[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.

[BUG]

Zitat von JasonDX:

Dagegen hilft aber nur Implementierungs-orientiertes testen.

Assertions sind gegebenenfalls auch ziemlich praktisch, um die Konsistens des Zustandes einer Klasse festzustellen.
Im Testcode sollten die wohl aktiviert sein

[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

[hoika]

Hallo,

also sorry, ich habe es nicht begriffen!
Wo ist denn nun das Problem?

Es gibt eine Klasse, die wird von einem Programm benutzt.
Das Programm muss also die Klasse mit Daten füttern.
Als Ergebnis liefert die Klasse irgendwas zurück.

Wo ist das Problem?

Die Testaufgabe muss doch heißen
"Funktioniert die Klasse?"


Heiko

[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.