Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.java > #12990
| From | "Christian H. Kuhn" <qno-news@qno.de> |
|---|---|
| Newsgroups | de.comp.lang.java |
| Subject | Re: JUnit Test von JButton: Action wird nicht erkannt |
| Date | 2016-07-15 00:08 +0200 |
| Message-ID | <duqgrdFtso5U1@mid.individual.net> (permalink) |
| References | <duo028Fb4qaU1@mid.individual.net> <nm8j8b$r9c$1@newsreader4.netcologne.de> |
Am 14.07.2016 um 19:47 schrieb Patrick Roemer: > Responding to Christian H. Kuhn: >> Vollständiger Code auf https://www.qno.de/gitweb/, Branch v0.8.4. > > Vielleicht bin ich nur zu doof, aber ich sehe in diesem Interface keinen > Weg, das ganze Projekt einfach auszuchecken. Ich hab auch gebraucht ... auschecken geht nicht, stattdessen kann man einen Snapshot runterladen, das ist ein Zip-File. Aufs gewünschte Projekt (oder dahinter auf shortlog) clicken, beim gewünschten Commit auf Snapshot. > wäre ein Link auf ein Zip oder, noch besser, ein clone des Repos auf > github o.ä., sinnvoller. GitHub kommt später. Ich habe versucht, apache und git mit „dummem“ http aufzusetzen. Bislang ohne Erfolg, das schaue ich mir später nochmal an. Wenn das läuft, ist ein einfaches Clonen über http möglich. > Was auf den ersten Blick auffällt: "Echtzeit" (System.nanoTime(), > java.util.Timer, etc.) in den Kernklassen hart zu verdrahten, ist schon > wegen der Tests nicht so der Knüller - die brauchen ja jetzt schon ewig... > > Ich würde das in irgendeine TimeSource-Abstraktion auslagern, die man in > den Tests mit gescripteten Zeitwerten/-events mocken kann. Ich hab ein wenig gebraucht, um zu begreifen, was du von mir willst :-) Ich glaube verstanden zu haben: Wenn ich nicht System.nanoTime() nehme, sondern eine AbstractTime.getTime(), dann kann ich „in echt“ den 50 ms-Takt zum Aktualisieren nehmen. Bei den Tests brauche ich keine Rücksicht auf Zeitabläufe zu nehmen, sondern setze die Zeiten so, wie ich sie brauche? > Presentation Model Einer der nächsten Schritte. Autonomous view klappt jetzt, quick and dirty. Da dort jedes Widget eine eigene Repräsentation seines Zustands hat, bekommt auch jedes seinen eigenen ActionListener. > Ansonsten hast Du auf jeden Fall noch ein Threading-Problem. Sowohl der > Test (main-Thread) als auch das Kernmodell (Timer-Threads) werkeln > direkt auf dem UI-Zustand rum. Das muss alles über den Swing-EDT laufen. > > Das ist kein rein akademisches Problem! Wenn ich im Debugger etwas mit > Breakpoints und Timings rumkaspere, schaffe ich es z.B., diesen Testfall > (natürlich nichtdeterministisch und nur selten) grün laufen zu lassen - > weil das Deaktivieren des Reset-Buttons noch nicht im EDT "angekommen" > ist und auch die stop-Action "untergeht". Das sieht dann etwa so aus: Um mich da rauszuwinden, habe ich in den Tests mit hinreichend langen Thread.sleep() gearbeitet. Und in der Tat gibt es Probleme. Die Wartezeit muss durch Ausprobieren so gewählt werden, dass der Test sowohl bei normaler Ausführung als auch bei der langsameren Coverage-Ausführung (und natürlich auch mit Breakpoint) grün bleibt. Unschön. Im Studium hatte ich Multi-Threading nur im ProPra, und der einzige wirkliche Lerneffekt war, dass der Datenfluss von einem Thread in den anderen EWIG dauert. Threadsicherheit, Transaktionen etc. hab ich mal gehört, im Prinzip verstanden, aber noch keinen praktischen Kontakt gehabt. Schien mir hier auch nicht nötig. In der gegebenen Situation (Schach) werden auch geübte Spieler nicht mehr als 2 Züge pro Sekunde machen. Bei einem 50ms-Takt passiert da nichts gravierendes. notifyObserver() überträgt immer nur die aktuellen Änderungen, und aufeinanderfolgende Aufrufe werden da keine vom Spieler wahrnehmbaren Störeffekte erzeugen. JUnit nimmt da etwas filigraner wahr. Und das überspiele ich zur Zeit noch mit Thread.sleep(). Mal schauen, was ich da wie in den EDT bekomme. Wobei ich denke, dass der TimerTask in QChessTimer unproblematisch ist. Zur Not wird auf flagFallen synchronisiert. Den TimerTask in QChessClock kann man womöglich ganz wegbekommen, wenn QChessTimer in seinem Takt auf Veränderungen in den Sekunden testet und dann QChessClock benachrichtigt. Wie das externe Setzen von GUI-Bestandteilen in den EDT rein soll, erschließt sich mir noch nicht. Im Moment sehe ich eigentlich nur, für ein Update von Eigenschaften entweder ein spezielles (unsichtbares) noch einzufügendes Element der GUI mit doClick() auszulösen oder einem ActionListener ein Event zuzuschicken. Beides wäre auf Swing spezialisiert, und für eine andere Oberfläche müsste ich das Modell umschreiben. Unschön. Ja, inzwischen weiss ich. Presentation Model hat das Problem nicht :-) Ich glaube, der nächste Schritt wird die Umstellung auf Presentation Model. Da unterhält sich nur das PM mit der GUI. lg QNo
Back to de.comp.lang.java | Previous | Next — Previous in thread | Next in thread | Find similar
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