Indirekte Kontrolle / GUI testen

[marluwie]

Hallo,
muss ich ein Test Stub, Test Spy, Mock Object (!) oder Fake Object testen? In diesem Zusammenhang auch noch die Frage: Für was steht noch mal DOC? Document?

Kann ich eine Klasse testen, die ausschließlich GUI-Verantwortlichkeit besitzt? Z.B. ob ein Bild richtig angezeigt wird. Im Endeffekt kann ich ja nur prüfen, ob ein GUI-Objekt den Auftrag bekommt, ein Bild anzuzeigen. Aber das Bild oder die korrekte Darstellung kann ich nicht prüfen. Das heißt: Im Endeffekt habe ich keine Ahnung, ob die GUI-Klasse den Darstellungsauftrag korrekt verarbeitet. Ich könnte mir höchstens noch vorstellen, dass man für die Darstellung ein Framework wie Swing voraussetzt und dann ein GraphicsTestSpy or whatever unterschieben würde. Geht das nicht schon zu weit für den Rahmen der Übung? Gibt es eine andere Möglichkeiten die tatsächlichen Animationen zu testen.
Viele Grüße, Marian!

[Wambolo]

Ich denke für eine reine GUI-Klasse ohne sonsitge Aufgabe kannst Du den Test weglassen, wie Du ja schon sagst würde das zu komliziert werden.

ACHTUNG: Das ist nur meine Einschätzung!

[sevenclev]

Getestet werden muss nur, dass die GUI-Klasse den Auftrag bekommt.
Was für ein Testpattern du benutzt ist dir überlassen, bzw. ist abhängig von deinem Design.

[marluwie]

Noch eine Frage. Muss man den Test Spy testen? Und das Mock Up oder der Test Stub? Schließlich sind das ja Klassen wie alle anderen auch und ich nehme an, dass sie in der Regel auch eine begrenzt komplexe Logik enthalten können.

[marcel_b]

Theoretisch musst du komplexe Logik auch testen - aber irgendwo greift auch hier der "Rekursionsanker". Deshalb sollen Testfälle auch so einfach wie möglich sein (nur ein Pfad, viele gemeinsam genutzte custom assert-, creator- oder finder-Methoden beinhalten, vorher mindestens einmal fehlgeschlagens ein usw.) um das Risiko von Fehlern zu minimieren. Man schreibt also i.d.R. keinen Testcode für den Testcode sondern höchstens für häufig genutzte Utility-methoden.