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