Swing Mocken von JOptionPane im JUnit-Test

[Nemesys88]

Hallo zusammen!

Ich habe einen JUnit-Test geschrieben. Dieser testet eine Methode, die eine JOptionPane wirft. Ich habe das Problem zwar jetzt umgangen, indem ich per Mocking einer anderen Variable garnicht erst zulasse, dass er in die If-Bedingung reingeht, wo die JOptionPane aufgerufen wird.

Jedoch würde mich trotzdem interessieren, um zu lernen, wie man JOptionPane richtig mockt.

Ich habe das einmal so versucht:

@PrepareForTest({ JOptionPane.class })
...     
PowerMockito.mockStatic(JOptionPane.class)
PowerMockito.doNothing().when(JOptionPane.class, "showMessageDialog", Component.class, Object.class);

Dies führt allerdings zu einer IllegalArgumentException:TypeMismatch. Das kann ich mir nicht wirklich erklären, da die Argumente Component und Object definitiv die richtigen Argumente der Methode showMessageDialog sind...

Das Benutzen der Annotation @RunWith: PowerMockRunner.class führte in einem vorherigen Test zu einer Linkage-Exception- im konkreten Zusammenhang mit einer JTable und dem RepaintManager...

Freue mich über eure Hinweise!

Gruß

 

[mrBrown]

Hm, der einfachste Weg: die Dinge so entkoppelt, dass der UnitTest nichts von der GUI mitbekommt.

 

[Nemesys88]

Ja. Das habe ich ja jetzt auch so gemacht. Ich habe jetzt noch Glück gehabt, dass der Aufruf in einer if-Bedingung war. (Per mocking konnte ich dann dafür Sorgern, dass die Bedingung während des Tests niemals erfüllt ist) Aber das ist halt Zufall, dass es so ging. Die JOptionPane kann auch mal an einer Stelle stehen, wo der Aufruf nicht so leicht abgefangen werden kann. Und wenn man dann nicht mehr am Code rumschrauben will, wird es blöd... Habe im Internet auch Lösungen gefunden, die dann ein eigenes Interface gemacht und eine komplett neue OptionPane definiert haben, das empfinde ich ein bisschen als overhead... Ich denke schon, dass es irgendwie so gehen kann wie im oberen Codefragment beschrieben, die Frage ist nur wie.... 😉

 

[mrBrown]

Ja. Das habe ich ja jetzt auch so gemacht. Ich habe jetzt noch Glück gehabt, dass der Aufruf in einer if-Bedingung war. (Per mocking konnte ich dann dafür Sorgern, dass die Bedingung während des Tests niemals erfüllt ist) Aber das ist halt Zufall, dass es so ging. Die JOptionPane kann auch mal an einer Stelle stehen, wo der Aufruf nicht so leicht abgefangen werden kann. Und wenn man dann nicht mehr am Code rumschrauben will, wird es blöd... Habe im Internet auch Lösungen gefunden, die dann ein eigenes Interface gemacht und eine komplett neue OptionPane definiert haben, das empfinde ich ein bisschen als overhead... Ich denke schon, dass es irgendwie so gehen kann wie im oberen Codefragment beschrieben, die Frage ist nur wie.... 😉

die Variante mit dem if ist zumindest überaus schlecht.

Wenn der Code nicht testbar ist, ist das umbauen genau die richtige Lösung 😉
Wozu schreibst du sonst Tests, wenn du den Code eh nicht ändern willst?

Die Variante mit dem Interface ist dafür eine Möglichkeit.
Was testest du denn überhaupt, das Model der Anwendung?