Unit-Test für private/protected Member?

[Uwe Raabe]

Zitat von JasonDX:

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.

[mjustin]

Zitat von mh166:

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.

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