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.


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

[Zacherl]

Zitat von 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

Fun fact: Delphi kennt "package private"

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.

[Jens01]

Zitat:

An sich habt ihr schon recht: durch das Testen der public Methoden wird implizit auch der Rest getestet.

Das gilt aber nur für Klassen, die einfache Aktionen machen. Wenn die Klasse Unstetigkeiten bei besonderen Konstellationen der Daten hat, kann man das meist nur bei den privaten Methoden abtesten.
Man könnte das "private" und "protected" mit einer Compiler-Direktive zu "public" machen. Das ist zwar mehr "Methode Brechstange", aber geht.

[mh166]

Zitat von Jens01:

Man könnte das "private" und "protected" mit einer Compiler-Direktive zu "public" machen. Das ist zwar mehr "Methode Brechstange", aber geht.

Hihi. Das klingt in der Tat nach Brechstange. Ich bleib für den Moment einfach erstmal beim Verhaltens-Test.

Soweit mir bekannt, sollte es aber im Moment zum Glück keine größeren Probleme mit widerspenstigen Daten geben: alles hübsches XML in regelmäßiger Form. Und ich hoffe, das bleibt auch so.

[JasonDX]

Zitat von mh166:

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?

Wenn man eine Methode indirekt testet, bekommt man Fehler aus dieser Methode auch nur indirekt mit - das stimmt. Dagegen hilft aber nur Implementierungs-orientiertes testen.

Zitat von mh166:

Ginge ja auch in Richtung möglichst hoher Code Coverage vom Test, oder?

Code Coverage ist höchstens ein Tool um festzustellen, dass man zu wenig Tests hat. Es ist nicht geeignet zu begründen, man hätte ausreichend oder gar gute Tests.

Zitat von Jens01:

Zitat:

An sich habt ihr schon recht: durch das Testen der public Methoden wird implizit auch der Rest getestet.

Das gilt aber nur für Klassen, die einfache Aktionen machen. Wenn die Klasse Unstetigkeiten bei besonderen Konstellationen der Daten hat, kann man das meist nur bei den privaten Methoden abtesten.

Alternativ:

1. Klasse aufteilen, dass sie einfachere Aktionen durchführt
2. Besondere Konstellationen durch entsprechende Methodenaufrufe produzieren, um den gewünschten, zu testenden Zustand zu erreichen
3. Den zu testenden Zustand der Klasse direkt setzen, wenn entsprechende Setter zur Verfügung stehen.

Testbarkeit ist ein Element von Codequalität

[Namenloser]

Zitat von mh166:

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.