Unit-Test für private/protected Member?

**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:

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

Testbarkeit ist ein Element von Codequalität

**Jens01**

Zitat:

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

Testbarkeit ist ein Element von Codequalität

Ja, geht bei einfacher Kompliziertheit. Wenns mehr wird, dann geht das nicht mehr und die Qualität des Testcodes nimmt rapide ab.

Auch das Aufteilen der Klasse bringt da nichts mehr. Es geht nicht um den Umfang der Klasse, sondern wie kompliziert die Logik ist, die umgesetzt wird.
Weiterhin gibt es Unstetigkeiten, die man mit einfachen setzen von Eingangsvariablen, nicht mehr treffen kann. (also mit vertretbaren Aufwand)

**JasonDX**

Es stimmt dass bei steigender Komplexität auch das Testen schwieriger wird. Dabei wird das Testen in diesen Fällen umso wichtiger, genauso wie sauberer, übersichtlicher, wartbarer - und eben testbarer - Code.

Zitat von Jens01:

Auch das Aufteilen der Klasse bringt da nichts mehr. Es geht nicht um den Umfang der Klasse, sondern wie kompliziert die Logik ist, die umgesetzt wird.

Man kann aber auch Logik aufteilen. Meistens durch Generalisieren einer Teillogik, und separaten Implementierung (&testen) dieser. Dann kann man diese auch separat testen. Tests für die ursprüngliche Klasse können dann eine Mock-Implementierung der Teillogik verwenden, was wiederum ein einfaches gezieltes Testen ermöglicht.

Zitat von Jens01:

Weiterhin gibt es Unstetigkeiten, die man mit einfachen setzen von Eingangsvariablen, nicht mehr treffen kann. (also mit vertretbaren Aufwand)

Vllt. nicht mit direktem setzen von Eingangsvariablen, aber man kann auf getestete Methoden zurückgreifen:

markieren

Code:

			testInstance = TestClass.create('testValue');

testInstance.doSomething('withTestValue');

testInstance.testTargetMethod('anothertestvalue');

entsprechend muss transferToState getestet sein, aber dann sollte das Problem auch lösbar sein.

**Mikkey**

Ich würde den Ansatz von Zacherl bevorzugen.

In C# haben wir die Möglichkeit genutzt, Klassen als "partial" zu definieren. Die Unit-Tests haben dann einfach die Klasse ergänzt.

Da Delphi alle Methoden einer Klasse in einer Quelldatei erwartet, sehe ich als einzige Möglichkeit, die Unit-Tests dort ebenfalls hineinzuschreiben. Im Relase lassen sich die Bereiche ja per ifdef ausblenden.

Ganz schlecht wäre m.E. Code im Unit-Test-Fall zu modifizieren, da läuft man ganz schnell Gefahr, etwas Anderes zu testen als den Programmcode. Und - ein Unit-Test soll eine Methode testen, das ist in der Regel nicht eine komplexe Funktion, die gerade noch public erreichbar ist.

**Jens01**

Zitat von JasonDX:

Vllt. nicht mit direktem setzen von Eingangsvariablen, aber man kann auf getestete Methoden zurückgreifen:

markieren

Code:

			testInstance = TestClass.create('testValue');

testInstance.doSomething('withTestValue');

testInstance.testTargetMethod('anothertestvalue');

entsprechend muss transferToState getestet sein, aber dann sollte das Problem auch lösbar sein.

Sorry, kann ich gerade nicht nachvollziehen, was Du meinst.

Zitat von JasonDX:

Es stimmt dass bei steigender Komplexität auch das Testen schwieriger wird.

Eigentlich nicht. Es bleiben -im Idealfall- kleine leicht testbare Klassen. Nur eben viel mehr. Aber das Testen selbst wird nicht komplexer, es dauert nur länger. Wir *machen* nur den Fehler, und lassen große Projekte immer komplexer werden, weil wir hier noch was ranbepseln, dort eine Funktion anflanschen usw.

Wichtig ist, das man Sperenzchen wie Threads und solchen Schnickschnack soweit wie möglich vermeidet, denn so ein Zeugs ist verdammt schwer zu testen. Wenn man Threads benutzen muss, dann am besten mit einem fertigen Framework, wie einer Jobqueue, Workerthreads oder ähnlichem. Überhaupt sollte alles, was die heile testbare Welt verlassen kann (eine 'Unit'), gekapselt werden, also nicht wie wild SQL-Befehler absetzen, wo es gerade passt oder eine Verbindung zu einer anderen Dimension herstellen.

**Zacherl**

Unter dem Aspekt, dass Klassen in der selben Unit gegenseitig auf private und protected Felder zugreifen können, hatte ich es mal folgendermaßen realisiert:

"Unit Test"-Unit anlegen mit ner Basisklasse TUnitTest und einer RegisterUnitTest Funktion
- Die Basisklasse bekommt eine abstrakte virtuelle Methode Test
In jeder Unit in der man eine oder mehrere Klassen testen willst, bindet man (unter Verwendung von IFDEF xxx) die "Unit Test"-Unit ein und deklariert sich eine Testklasse, die von TUnitTest ableitet.
- Jetzt kann man die virtuelle Test Methode überschreiben und fleißig testen.
Im initialization Teil der Unit ruft man zum Schluss noch schnell RegisterUnitTest für jede vorhandene Testklasse auf.

In der Hauptunit implementiert man sich die RegisterUnitTest Funktion im Optimalfall so, dass alle Testobjekte in einer Liste abgelegt werden, die man dann beim großen Test einfach sequentiell durcharbeitet.

**JasonDX**

Zitat von Mikkey:

Und - ein Unit-Test soll eine Methode testen, das ist in der Regel nicht eine komplexe Funktion, die gerade noch public erreichbar ist.

Nein, ein Unit-Test soll nicht eine einzelne Methode testen. Das Aufrufen von einzelnen Methoden geschieht deshalb, weil diese Methoden das Verhalten der Implementierung definieren. Dieses Verhalten ist, was eigentlich getestet wird.
Es gibt für jede Spezifizierung einer Klasse mehrere korrekte Implementierungen. Ein Unit-Test soll nicht prüfen ob eine bestimmte dieser korrekten Implementierungen verwendet wurde, sondern ob es sich überhaupt um eine korrekte Implementierung handelt, und beschreibt bei falschen Implementierungen, welche Verhaltensanforderung nicht erfüllt wurde.

Zitat von Jens01:

Zitat von JasonDX:

Vllt. nicht mit direktem setzen von Eingangsvariablen, aber man kann auf getestete Methoden zurückgreifen:

markieren

Code:

			testInstance = TestClass.create('testValue');

testInstance.doSomething('withTestValue');

testInstance.testTargetMethod('anothertestvalue');

entsprechend muss transferToState getestet sein, aber dann sollte das Problem auch lösbar sein.

Sorry, kann ich gerade nicht nachvollziehen, was Du meinst.

Es geht ums Testen von Methoden einer Klasse, die einen bestimmten Zustand beschreibt, und wie man diesen Zustand in einem Unittest erreicht.
Mein Beitrag ging darauf ein, dass das Erreichen dieses Zustandes auch mit Hilfe von bereits getesteten Methoden der Klasse geschehen kann.

Zitat von Dejan Vu:

Zitat von JasonDX:

Es stimmt dass bei steigender Komplexität auch das Testen schwieriger wird.

Eigentlich nicht. Es bleiben -im Idealfall- kleine leicht testbare Klassen. Nur eben viel mehr. Aber das Testen selbst wird nicht komplexer, es dauert nur länger. Wir *machen* nur den Fehler, und lassen große Projekte immer komplexer werden, weil wir hier noch was ranbepseln, dort eine Funktion anflanschen usw.

Da hast du an sich recht, ich hab mich auch weng falsch ausgedrückt. Das, was im Endeffekt schwieriger wird, ist die saubere Zerteilung eines komplexen Problems in kleinere, einfache Teilprobleme.