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

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

Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle

Show all headers | View raw

In article <du7ob7Fecu7U1@mid.individual.net>, Christian H. Kuhn (qno-
news@qno.de) says...
> 
> Hallo Gemeinde,
> 
> Bevor hier der Löschantrag wegen Inaktivität kommt, mach ich doch lieber
> nochmal Traffic :-)

> 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.

Ich bin bei sowas ganz pragmatisch.
Gibt öffentliche Methoden, die ich testen kann, dann mache ich das 
bevorzugt.
Bietet sich eine protected Methode zum Test an, hae ich die Möglichkeit 
von der zu testenden Klasse eine Klasse abzuleiten und habe so Zugriff 
auf die Methode der Ableitung - die ruft ledglich super auf, also ändere 
ich das Verhalten wenig bis gar nicht, bzw. überschaubar genug, um eine 
informierte Entscheidung zu treffen, inwiefern der Test was taugt.

Bei private Methoden habe ich wenig Schmerzen damit die Sichtbarkeit von 
"private" auf "default" zu ändern, allerdings mit einem Javadoc-
Kommentar, dass die Sichtbarkeit nur wegen JUnit auf "default" gesetzt 
wurde. Da Test und Testobjekt in einem package leben, habe ich Zugriff 
auf die Methode und kann fröhlich testen. Ich erlaube mir as, weil der 
bliche Code, den man so schreibt, ohnehin kein Frameworks für die 
Öffentlichkeit ist, bzw. nicht den Charakter einer Bibliothek für die 
breite Masse hat. Kurz: Man hat den Source der Klasse und den, der sie 
verwendet, in der Regel gut genug unter Kontrolle, um sich damit kein 
eigenes Bein zu stellen.

Ich benutze übrigens EclEmma (Emma- Plugin für Eclipse), um mir dabei zu 
helfen heraus zu finden, ob ich gewisse Fälle vergessen habe.

> Bleibt eigentlich nur, dass die Testklasse QChessClockObserver
> implementiert und auf die Benachrichtigungen des Observable wartet. Der
> Weg ist gangbar, ich habe ihn aber noch in keinem Buch gefunden. Daher
> vermute ich, dass es da eleganteres gibt?

Ich finde nichts Falsches daran eine Klasse so zu testen, dass du eine 
Test-Listener an die Klasse hängst, und die Events abfragst, die da raus 
kommen. Schließlich sind die geworfenen Events Teil der API, bzw. eines 
Methoden-Contracts und gehören deswegen getestet. Wenn du zusicherst in 
einer bestimmten Situation ein Event zu werfen, sollte dein Test auch 
prüfen, ob das geschieht, sofern das für das Programm wichtig ist.

> In noch extremerem Umfang gilt das für die Java-GUI.


[..]

> Auch für den Integrationstest des gesamten
> Systems scheint JUnit das falsche Mittel zu sein.

JUnit halte ich für ein Mittel, welches gut genug dafür ist einzelne 
Komponenten zu testen, auch wenn es UI-Kompoinenten sind. Hierbei musst 
du aufpassen, dass du alles im EDT ausführst, Konstruktion der Panels, 
setzen und abfragen der Listener, erzeugen, abfragen und setzen von 
Werten, das Finden von Buttons und Dropdowns in der Komponenten-
Hierarchie. etc.. und du solltest einen Timeout für alle Aktionen haben, 
der zwar nicht zu knapp bemessen ist (bei mir sind es etwa 10 Sekunden), 
aber du willst, dass einzelne Tests fehlschlagen können, ohne dass die 
dentest auf Ewig raus zögern, weil du einen Test verkackt hast und der 
z.B. ewig auf ein Ergebnis wartet.
Solche UI-Tests kannst du auch auf einem Jenkins-Server laufen lassen, 
wenn du ein virtuelles Display hast (Linux, Display-Variable), auf dem 
die Komponenten gerendert werden können. Problem hierbei ist: Du musst 
sicherstellen, dass Tests niemals gleichzeitig ausgeführt werden und 
dass Frames vollständig geschlossen sind, bevor ein neuer Test gestartet 
wird. Mitunter ist das etwas tricky, aber machbar. Leider ist es auch 
langsam, aber mit dieser Methode habe ich die Test-Coverage von UI-Code 
in unserer Codebase dramatisch erhöht - und natürlich sehe ich im Emma-
Plugin, wo er durch gerannt ist.
Für den Integrationstest einer komplette Applikation halte ich es nict 
für das richtige Mittel, aber einzelne Komponenten (also ne Suchmaske 
mit ein paar Knöpfen, etc), kann man so recht ordentlich testen und 
deckt auch den einen oder anderen, überraschenden Fehler auf.
Es hilft aber ein Flag zu haben, um diese UI-tests zu überspringen, weil 
du in der Zeit, in der die auf deinem Entwicklungsrechner laufen, 
praktisch nicht arbeiten kannst, weil du mausklicks simulierst - 
abgesehen davon, dass sie langsam sind. Du willst alle normalen Tests 
oft und schnell durchführen und die lahmen UI-Tests nur an und zu, vor 
der Kaffeepause oder vor dem Commit laufen lassen, bzw. regelmäßig auf 
dem CI-Server.

Gruß,
-Wanja-

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

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