Unit testet eine Swing-Komponente

7

Ich schreibe eine TotalCommander-ähnliche Anwendung. Ich habe eine separate Komponente für die Dateiliste und ein Modell dafür. Modell unterstützt Listener und gibt auf folgende Weise eine Benachrichtigung für Ereignisse wie CurrentDirChanged usw. aus:

%Vor%

Ich habe einen einfachen Test dafür geschrieben:

%Vor%

Das funktioniert nicht, weil es kein EventDispatchThread gibt. Gibt es eine Möglichkeit, dies innerhalb des Headless-Builds zu testen?

Komponententest Java Swing jmock

    
Ula Krukar 26.09.2009, 09:28
quelle

5 Antworten

11

Hinweis: Im Allgemeinen ist das Testen von Einheiten auf UI-Objekten immer schwierig, weil Sie eine Menge Dinge ausstellen müssen, die gerade nicht verfügbar sind.
Daher besteht das Hauptziel beim Entwickeln von Anwendungen (von jedem Typ) immer darin, zu versuchen, Benutzeroberflächen von der Hauptanwendungslogik so weit wie möglich zu trennen. Da es hier starke Abhängigkeiten gibt, ist Unit-Testing wirklich schwierig, im Grunde ein Albtraum. Dies wird normalerweise durch die Verwendung von Mustern wie einer MVC Art von Ansatz, wo Sie hauptsächlich Ihre Controller-Klassen testen und Ihre Ansichtsklassen nichts tun, als die Benutzeroberfläche zu erstellen und ihre Aktionen und Ereignisse an die Controller zu delegieren. Dies trennt Verantwortlichkeiten und erleichtert das Testen.

Darüber hinaus sollten Sie nicht unbedingt Dinge testen, die bereits vom Framework bereitgestellt werden, z. B. testen, ob Ereignisse korrekt ausgelöst werden. Sie sollten nur die Logik testen, die Sie selbst schreiben.

    
Juri 26.09.2009, 09:46
quelle
12

Schauen Sie dies :

  

FEST ist eine Sammlung von Bibliotheken, die unter der Apache 2.0-Lizenz veröffentlicht wurde und deren Aufgabe es ist, das Testen von Software zu vereinfachen . Es besteht aus verschiedenen Modulen, die mit TestNG oder verwendet werden können JUnit ...

    
user179460 26.09.2009 11:48
quelle
2

Überprüfen Sie das uispec4j-Projekt. Das ist, was ich benutze, um meine UIs zu testen.

www.uispec4j.org

    
Pigelvy 29.09.2009 11:40
quelle
2

Ich denke, dass das Problem beim Testen ein Problem mit dem Code aufdeckt. Es sollte nicht wirklich die Aufgabe des Modells sein, zu entscheiden, ob es im Versandthread läuft, das sind zu viele Verantwortlichkeiten. Es sollte nur seinen Benachrichtigungsjob ausführen und eine aufrufende Komponente entscheiden lassen, ob sie es direkt aufruft oder invokeLater aufruft. Diese Komponente sollte in dem Teil des Codes sein, der Swing-Threads kennt. Diese Komponente sollte nur über Dateien und ähnliches wissen.

    
Steve Freeman 30.09.2009 12:36
quelle
1

Ich arbeite erst seit zwei Tagen mit jMock ... also bitte entschuldigt mich, wenn es eine elegantere Lösung gibt. :)

Es scheint so, als ob Ihr FileTableModel auf SwingUtilities angewiesen ist ... haben Sie sich über die SwingUtilities Gedanken gemacht, die Sie benutzen? Eine Art, die wie ein Hack riecht, aber das Problem lösen würde, wäre, eine Schnittstelle zu erstellen, sagen ISwingUtilities, und eine Dummy-Klasse MySwingUtilities zu implementieren, die einfach an die echten SwingUtilities weiterleitet. Und dann können Sie in Ihrem Testfall die Schnittstelle mockern und für isEventDispatchThread true zurückgeben.

%Vor%     
Philip Davis 30.09.2009 04:55
quelle

Tags und Links