Unit-Test für private/protected Member?

[mh166]

Hi Leute,

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. ;)

Ich hatte schon überlegt jeweils ne Klasse abzuleiten und darin dann eine öffentliche Zugriffsmethode auf die privaten Member zu erstellen. Aber ich denk das ist von hinten durch die Brust ins Auge. Kann ja nicht Sinn und Zweck sein. Zumal dann die Übersichtlichkeit wohl stark leidet.

Eine zweite Idee: Die TestFixture-Klasse statt von TObject von der zu testenden Klasse ableiten und so Zugriff auf die protected-Member bekommen. Aber das ist ja nochmal widersinniger: von allem guten OOP-Geistern verlassen, müsste die Klasse sich selber vorbereiten, testen und wieder freigeben. Ist ja gruselig. :pale:


Daher meine ratlose Frage an euch: wie testet man denn nun am besten private/protected Member (mit DUnitX in meinem Fall) auf korrekte Funktionsweise? Wie löst ihr das?

[Sherlock]

Also meine Gedanken dazu sind folgende: Die privaten Member sind ja hoffentlich nötig, um public zu einem Ergebnis zu kommen, korrekt? Wenn das Ergebnis nach aussen also stimmt, und alle privaten Member wirklich sinnvoll gebraucht werden, dann ist doch alles in Butter.

Sherlock

[Klaus01]

.. die private/protected Methoden werden nur durch die public Methoden genutzt.
Werden die dann nicht getestet wenn die public Methoden getestet werden?

Grüße
Klaus

[Der schöne Günther]

Würde Delphi Namensräume kennen und einen zusätzlichen Sichtbarkeitsmodifikator (neben public, protected und private) anbieten für "Alles was in meinem Namensraum ist darf das sehen" würde man die Testklasse in den gleichen Namensraum packen und könnte alles mit dem "package"-Sichtbarkeitsmodifikator auch testen :stupid:

[Namenloser]

Zitat:

Zitat von mh166 (Beitrag 1271764)

Ich hatte schon überlegt jeweils ne Klasse abzuleiten und darin dann eine öffentliche Zugriffsmethode auf die privaten Member zu erstellen. Aber ich denk das ist von hinten durch die Brust ins Auge. Kann ja nicht Sinn und Zweck sein. Zumal dann die Übersichtlichkeit wohl stark leidet.

So habe ich das für protected-Methoden bisher immer gemacht. Private Methoden kann man mit keiner der beiden Varianten testen. Ich persönlich verwende die private Sichtbarkeit allerdings ungefähr so sparsam wie goto.

[JasonDX]

Das Testen von privaten Methoden sollte implizit durch das Testen von public methods passieren. Teste das Verhalten einer Klasse, nicht ihren Code.

[mjustin]

Zitat:

Zitat von mh166 (Beitrag 1271764)

wie testet man denn nun am besten private/protected Member (mit DUnitX in meinem Fall) auf korrekte Funktionsweise? Wie löst ihr das?

Protected Methoden kann man durch eine abgeleitete Klasse, in der die Methode public re-deklariert wird, sichtbar und damit testbar machen.

[Uwe Raabe]

Zitat:

Zitat von JasonDX (Beitrag 1271771)

Das Testen von privaten Methoden sollte implizit durch das Testen von public methods passieren. Teste das Verhalten einer Klasse, nicht ihren Code.

Genau! Das hat den Vorteil, daß man die Tests unverändert beibehalten kann, wenn sich die Implementation der Klasse ändert. Ist das nicht eigentlich auch der Sinn von Unit-Tests, daß sie über das interne Vorgehen keine Ahnung haben (müssen)?

Man kann sich das auch so vorstellen: Schreibe die Tests so, daß du die zu testende Klasse durch eine andere Klasse ersetzen kannst, die das gleiche Interface bereitstellt und die gleiche Funktionalität hat.

[mh166]

An sich habt ihr schon recht: durch das Testen der public Methoden wird implizit auch der Rest getestet. Aber zur Lokalisierung von Fehlern wäre es ja doch einfacher, wenn man gleich weiß, wos kracht als wenn man in der Public-Methode dann erst debuggen muss, bei welcher Aktion es denn nun warum genau kracht? Ginge ja auch in Richtung möglichst hoher Code Coverage vom Test, oder?

Aber gut, ich werds wohl wirklich so machen: Verhalten testen und nicht Code. (Der Satz stellt Unit-Tests für mich gleich in einem ganz anderen Licht dar. :idea: ) Klingt am vernünftigsten – es spart das Gebastel mit den private/protected Membern und es verkürzt den effektiven Code, da ich nicht jede Funktion einzeln testen muss.

[Zacherl]

Zitat:

Zitat von Der schöne Günther (Beitrag 1271769)

Würde Delphi Namensräume kennen und einen zusätzlichen Sichtbarkeitsmodifikator (neben public, protected und private) anbieten für "Alles was in meinem Namensraum ist darf das sehen" würde man die Testklasse in den gleichen Namensraum packen und könnte alles mit dem "package"-Sichtbarkeitsmodifikator auch testen :stupid:

Fun fact: Delphi kennt "package private" :D

Naja genau betrachtet ist es eher ein "Unit-private", aber vom Prinzip her funktionierts genauso. Wenn du zwei Klassen in der selben Unit deklarierst, kannst du ohne Probleme gegenseitig auf private Felder zugreifen. Wenn du das verhindern willst, musst du sie als strict private deklarieren.