Unit-Test für private/protected Member?

[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

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

[Dejan Vu]

Korrekt. Man muss wirklich unterscheiden zwischen:

• Legacy-Code 'as is', bei dem man mit möglichst wenig Trickserei akzeptable Tests bekommt.
• Neuen Code, wo ich mit den entsprechenden Programmierparadigmen perfekte(*) Tests bekommen kann.

(*) Perfekt <> 100% Coverage !