Unit-Test für private/protected Member?

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

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.

[Jens01]

Zitat von JasonDX:

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

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.

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

1. "Unit Test"-Unit anlegen mit ner Basisklasse TUnitTest und einer RegisterUnitTest Funktion
   • Die Basisklasse bekommt eine abstrakte virtuelle Methode Test
2. 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.
3. 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.

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

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.