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

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

Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle

Show all headers | View raw

Responding to Christian H. Kuhn:
> Bei QChessClock habe ich nicht den Schimmer einer Vorstellung, wie ich
> die Klasse testen soll. Es gibt keine Getter-Funktionen, mit denen sich
> was überprüfen ließe. Ich kann also testen, dass das Testobjekt nach
> Konstruktor ungleich null ist, sonst nichts. Eine Änderung der
> Schnittstelle nur zu Testzwecken kommt selbstverständlich nicht in
> Frage. Bleibt eigentlich nur, dass die Testklasse QChessClockObserver
> implementiert und auf die Benachrichtigungen des Observable wartet.

Variante: Der Test *erzeugt* ein Exemplar des Observer-Interface, das
entweder Assertions beinhaltet, oder eingehende Events speichert und
Methoden bietet, über die der Test diese später abfragen kann, um
Assertions darauf loszulassen.

> Der
> Weg ist gangbar, ich habe ihn aber noch in keinem Buch gefunden.

Genau dieser Ansatz sollte eigentlich in jedem TDD-Buch abgehandelt
werden. Die Nomenklatur ist allerdings herzlich inkonsistent: Das läuft
unter "Mock", "Shunt", "Stub", "Fake",... Bei Beck[1] ist das etwa ein
"(Self) Shunt" (und verwendet genau Dein Beispiel: Ein Test, der selber
ein Listener-Interface implementiert), während ein "Mock" eher ein nicht
verifizierender Drop-In für eine komplexe Ressource ist. Bei Meszaros[2]
heisst es hingegen "Test Spy" bzw. eben "Mock" (und Becks "Mock" wäre
ein "Fake Object").

> In noch extremerem Umfang gilt das für die Java-GUI. Die GUI erzeugt ein
> QChessClock-Objekt und registriert sich dort als Observer. Sie stellt
> die erwähnten Knöpfe und Menüs bereit, die auf die öffentlichen Methoden
> der Schachuhr zugreifen. Öffentliche Methoden sind außer dem Konstruktor
> und actionPerformed() noch die verschiedenen update()-Funktionen, über
> die das Observable seine Zustandsänderungen mitteilt. Auch hier habe ich
> praktisch nichts, was ich mit JUnit testen könnte, und andere Tests der
> Klasse kenne ich nicht.

Ich kann kaum glauben, dass eine Websuche mit "swing junit" nichts
zutage fördert...

GUI-Testing ist mühsam und IMHO recht spaßfrei. Es empfiehlt sich
deshalb (und nicht nur deshalb), möglichst viel Präsentationslogik in
eigenständig testbaren Klassen zu halten, die nicht nur innerhalb der
GUI-Eventloop lauffähig sind. Ein solcher Ansatz wäre z.B. Presentation
Model[3].

Um die korrekte Verkabelung des Modells mit den Widgets zu testen, muss
man entsprechende APIs des GUI-Frameworks verwenden, mit denen man
Widgets auffinden, ihre Zustände abfragen und Events auslösen kann.
Swing bietet sowas, und darauf basierend gibt es diverse auf JUnit
aufsetzende GUI-Test-Frameworks.

Bis zu einem gewissen Grad kann man sicher auch mit diesen Mitteln noch
testen, ob die GUI halbwegs so aussieht, wie erwartet (Positionierung,
Pixelfarben,...). So extrem bin ich aber selber noch nie geworden. :)

Viele Grüße,
Patrick

[1] Kent Beck, "Test-Driven Development by Example"
[2] Gerard Meszaros, "xUnit Test Patterns"
[3] http://www.jgoodies.com/download/presentations/patterns-and-binding.pdf

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

Thread

Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-07 21:19 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Peter <peter@localhost.com> - 2016-07-07 22:37 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Michael Paap <feunews@mpaap.de> - 2016-07-07 23:21 +0200
      Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-08 14:09 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-08 22:10 +0200
      Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-09 00:17 +0200
        Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-18 00:33 +0200
          Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-18 01:01 +0200
          Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-19 10:58 +0200
            Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-21 00:07 +0200
          Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 14:09 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-08 00:28 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-08 14:13 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-08 16:05 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-08 22:35 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-09 00:01 +0200
      Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-11 00:40 +0200
        Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 23:25 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 00:12 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-08 21:57 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-11 01:13 +0200

csiph-web