Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.java > #13032

Re: JUnit Test von JButton: Action wird nicht erkannt

Show all headers | View raw

Version 0.12.6

Am 20.07.2016 um 13:00 schrieb Patrick Roemer:
> Gemäß wall-time ist dem auch so. Damit ist aber noch nicht garantiert,
> dass C die Auswirkungen von Aktionen in B auch sieht. Und *das* ist,
> worum es bei happens-before-Beziehungen geht.

Nächster Versuch. Vielleicht habe ich es diesmal richtig verstanden. Ich
nehme es mal als gutes Zeichen, dass ich eine Menge Code gestrichen habe :-)

QChessClock:

Auf Eigenschaften wird schreibend nur durch die Methoden von
QChessClockInterface und durch addObserver() zugegriffen. Gelesen werden
die Eigenschaften nur durch den Bau des Austauschobjekts in
notifyObservers(). Damit sich diese Methoden nicht in die Quere kommen,
werden sie mit synchronized (this) synchronisiert.

Auf expliziten Aufruf von notifyObservers() nach jeder Zustandsänderung
wird verzichtet. Der Zustand der Clock wird alle 20ms an die Observer
verschickt.

QChessClockJavaAV:

GUI-Events und das folgende actionPerformed() sowie die darin
aufgerufenen Methoden liegen schön brav nacheinander auf dem Swing-EDT.
Diese Methoden führen nicht mehr zu einem notifyObservers() und damit zu
einem update(). update() wird nur noch vom TimerTask der Clock via
notifyObservers() aufgerufen und legt alle Zustandsänderungen der GUI
per invokeLater auf den Swing-EDT.

Mögliches Problem: Es könnte sein, dass die Clock einen Zustand annimmt,
in dem ein bestimmter Methodenaufruf unzulässig oder unsinnig ist. Die
Clock ist in diesem Zustand und teilt ihn beim nächsten Click an die GUI
mit. setEnabled(false) für das entsprechende GUI-Element wird auf den
Swing-EDT gelegt und dann auch irgendwann ausgeführt. In der Zeit
zwischen Zustandsänderung der Clock und Sperren des Bedienelements
könnte dieses ausgelöst worden sein und seinen in der Clock nicht mehr
sinnvollen Befehl ausführen. Die Clock muss also unsinnige Eingaben
abfangen. Meines Erachtens tut sie das schon. Ein künftiges Refactoring
während der noch folgenden Zustandserweiterungen könnte möglicherweise
eine Umstellung auf das State- oder Strategy-Entwicklungsmuster beinhalten.

Normaler Ablauf:

Drei Threads. Main erstellt die GUI. Swing-EDT führt GUI-Kommandos und
GUI-Aktualisierungen aus. TimerTask benachrichtigt GUI über
vorzunehmende Änderungen. GUI-Zustand und Clock-Zustand sind nicht
unbedingt synchron. Im normalen Anwendungsfall ändert sich das aber
spätestens durch den nächsten TimerTask. Wann genau der bzw. die von ihm
per invokeLater() ausgelösten Änderungen der GUI wirksam sind, ist so
nicht vorhersehbar. Ich bleibe aber dabei, dass das Risiko, dass ein
notifyObservers() nicht innerhalb der 20ms bis zum nächsten Aufruf
fertig abgeschlossen ist, für sehr überschaubar. Die Inkonsistenz wird
also vom menschlichen Spieler nicht bemerkt.

Tests:

In Tests ist es etwas anderes. Aufeinanderfolgende Methodenaufrufe
erfolgen so schnell hintereinander, dass notifyObservers() dazwischen
eher nicht aufgerufen wird. Daher müssen hier Threads synchronisiert werden.

QChessClockTest:

Die Testklasse implementiert eine Oberfläche, also insbesondere
update(). Die Tests verlaufen so, dass eine neue Clock mit spezieller,
aus dem Test veränderbarer Zeitquelle erstellt wird. Der Test ruft die
zu testende Bedienfunktion auf und/oder verändert die Zeit der Quelle.
Danach wird überprüft, ob die gewünschte Zustandsänderung per update()
übertragen wird. Da nicht vorauszusehen ist, wieviel Zeit zwischen
Aufruf der Methode und Zustandsübertragung erfolgt, wird per guarded
block auf das Ende des update() gewartet.

QChessClockJavaAVTest:

Die Testklasse implementiert die Interfaces QChessClockObservable und
QChessClockInterface. Zu Beginn eines Tests wird eine neue GUI erstellt,
die sich mit addObserver() bei der Testklasse registriert. Das zu
testende GUI-Element wird auf dem Swing-EDT mit invokeAndWait(() ->
doClick()) ausgelöst. Damit wird über actionPerformed() die
entsprechende Methode in der Testklasse aufgerufen und eine
entsprechende Zustandsänderung ausgeführt. Der EDT wird nicht verlassen,
daher wartet invokeAndWait(), bis die dem Event zugeordnete Methode
fertig ausgeführt ist. Das Testklassenobjekt ist damit in einem
testbaren Zustand, und der entsprechende assert kann ausgeführt werden.

Die andere Richtung, Uhr-Zustandsänderungen führen zu Änderung der
Darstellung, wird bislang nur durch Änderungen des Status getestet.
getestet. Hier wird der Zustand der Uhr gesetzt, der dann im TimerTask
per notifyObservers() an die GUI übertragen wird. Der Test muss dann im
guarded Block auf die Nachricht von notifyObservers warten, dass alle
beauftragten GUI-Änderungen auf dem EDT liegen, und kann nach Ende des
wait() die entsprechenden GUI-Eigenschaften abfragen.

Lediglich der aboutTest() macht mir noch Kopfweh. Da warte ich per
sleep() einen geschätzten Zeitraum darauf, dass ein JOptionPane
aufgebaut wird, um den Button abfragen zu können. Gibt es da keine
geschicktere Lösung? invokeAndWait() zum Aufruf des entsprechenden
Menüpunkts geht nicht, weil der Aufruf solange wartet, bis der
schließende Button gedrückt wird, und dann ist das Pane halt weg und
kann nicht mehr untersucht werden.

lg
QNo

Back to de.comp.lang.java | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-14 01:09 +0200
  Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-14 18:26 +0200
  Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-14 19:47 +0200
    Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 00:08 +0200
      Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-15 22:04 +0200
        Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 22:53 +0200
        Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 23:09 +0200
          Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-15 23:44 +0200
            Countdown Timer Design (was: JUnit Test von JButton: Action wird nicht erkannt) "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-16 23:44 +0200
              Re: Countdown Timer Design "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-17 12:44 +0200
              Re: Countdown Timer Design "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-17 15:49 +0200
                Re: Countdown Timer Design "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-17 17:03 +0200
                Re: Countdown Timer Design "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 15:59 +0200
        Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 14:59 +0200
          Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 16:06 +0200
          Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-19 18:59 +0200
            Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 22:35 +0200
              Re: JUnit Test von JButton: Action wird nicht erkannt Patrick Roemer <sangamon@netcologne.de> - 2016-07-20 13:00 +0200
                Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-23 20:36 +0200
                Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-23 23:15 +0200
          Re: JUnit Test von JButton: Action wird nicht erkannt Wanja Gayk <brixomatic@yahoo.com> - 2016-07-19 23:02 +0200
            Re: JUnit Test von JButton: Action wird nicht erkannt "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-20 12:33 +0200
    GUI-Update über Swing-EDT (was: JUnit Test von JButton: Action wird nicht erkannt) "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 12:03 +0200
      Re: GUI-Update über Swing-EDT Patrick Roemer <sangamon@netcologne.de> - 2016-07-15 22:43 +0200
        Re: GUI-Update über Swing-EDT "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 23:18 +0200
        Re: GUI-Update über Swing-EDT "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-16 15:24 +0200
          Re: GUI-Update über Swing-EDT Patrick Roemer <sangamon@netcologne.de> - 2016-07-16 16:42 +0200
            Re: GUI-Update über Swing-EDT "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-16 23:05 +0200
              Re: GUI-Update über Swing-EDT "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-17 16:02 +0200

csiph-web