JUnit: Testen ob bestimmte Exception nicht auftritt

[aze]

Hi

Kann man mit JUnit auch testen ob eine ebstimmte Exception nicht geworfen wird ?

Schöne Grüße

Aze

 

[bygones]

wenn eine exception geworfen wird, muss das System das doch wissen ?!

was machst du mit der Exception ansich - einfach schlucken ?

 

[aze]

Also es ist so:

Ich habe einen Sicherheitsaspekt geschrieben, der Alarm schlägt wenn bestimmte Benutzer bestimmte Funktionen aufrufen.Das zu testen ist ja leicht mit @Test[expected=MySecurityException].

Wie ist jetzt aber der Umkehrfall ? Also ein Benutzer ruft eine zulässige Funktion auf. Da möchte man ja testen ob dies nicht die Exception "MySecurityexception" erzeugt.

 

[maki]

Wenn eine Exception auftritt ist der test fehlgeschlagen, ausser du erwartest die Execption.

 

[tfa]

Wenn eine Exception fliegt, schlägt der Test doch sowieso fehl.

 

[aze]

Wenn eine Exception fliegt, schlägt der Test doch sowieso fehl.

Das stimmt. Ich möchte aber testen, dass er nicht wegen der Exception"MySecurityException" fehlschlägt. Mir geht es darum in disem Test NUR den Sicherheitsaspekt zu testen.

 

[faetzminator]

try {
    // ...
catch (MySecurityException e) {
   fail("this should not happen");
}

Aber das macht wirklich kein Sinn...

 

[bygones]

du stellst den relevanten code in ein try und faengst deine Exception ab...

@Test
public void foo() {
   try {
      // do something
   }
   catch(MySecurityException e) {
     // this is allowed here
   }
}

btw - ich wuerde von @Test[expected=MySecurityException] abstand halten, wenn dein Test nicht ein Einzeiler ist oder sie so spezifisch ist dass sie nur an einer Stelle auftreten kann.
Wenn die Exception in Zeile 5 oder so erwartet wird, aber aufgrund eines anderen Fehlers schon in Zeile 2 geschieht hast du nur einen scheinbar gruenen Test.

Ich nutz da lieber noch die try/catch mit fail Umsetzung.

btw2 - Mockito zb kann [c]assertThat(e).isInstanceOf(IOException.class);[/c]

 

[tfa]

Es ist doch aber genau so ein Fehler, wenn die Methode wegen jeder anderen, unbehandelten Exception abbricht. Und den findet JUnit ob du willst oder nicht.

 

[Empire Phoenix]

Klingt nach typischen fall von, aber die Designrichtlinien sagen, dass wir

 

[aze]

Es ist doch aber genau so ein Fehler, wenn die Methode wegen jeder anderen, unbehandelten Exception abbricht. Und den findet JUnit ob du willst oder nicht.

Richtig.Aber das soll woanders getestet werden.

Ich will einfach nur testen OB die Methode ausgeführt wird und nicht WIE.Wenn jemand eine bessere Lösung kennt dann bin ich auch dafür dankbar !

 

[bygones]

ist schwer zu sagen wenn man den code an sich nicht kennt bzw die Gegebenheiten.

Unter der Annahme es ist ein valider Fall kannst du mock bzw spy frameworks nutzen (zb Mockito) und dann verifizieren, dass bestimmte methoden aufgerufen wurden.

 

[nillehammer]

Eine Methode hat i.d.R. Seiteneffekte, die man beobachten kann, z.B.:
- Sie liefert einen return-Code
- Sie ändert eine Variable (entweder als Parameter übergeben oder in einer Instanz)
- Sie schmeißt eine Exception.
Um herauszufinden, OB eine Methode aufgerufen wurde, musst Du auf einen dieser Seiteneffekte testen. Das setzt natürlich voraus, dass Du irgendwie an diese Seiteneffekte "herankommst". Wenn Du das nicht kannst, ist die Methode schlicht nicht (Unit-)testbar.

 

[tfa]

Sie liefert einen return-Code
...
Sie schmeißt eine Exception.

Also das sind nun wirklich keine "Seiten-Effekte".

 

[bygones]

. Wenn Du das nicht kannst, ist die Methode schlicht nicht (Unit-)testbar.

das stimmt so nicht - wie oben geschrieben mit entsprechenden Spyframeworks ist es moeglich.

Man testet in dem Fall keine Logik seiner Unit, aber sozusagen die Choreografie

 

[nillehammer]

Also das sind nun wirklich keine "Seiten-Effekte".

Was wäre denn ein besseres Wort? Ich wollte halt damit ausdrücken, dass man nach dem Ablauf einer Methode i.d.R. an einer bestimmten Stelle außerhalb der Methode Effekte beobachten kann.

das stimmt so nicht - wie oben geschrieben mit entsprechenden Spyframeworks ist es moeglich.

Man testet in dem Fall keine Logik seiner Unit, aber sozusagen die Choreografie

Vielleicht fasse ich den Begriff "Unit-Test" etwas zu eng, aber wenn ich externe Werkzeuge benutzen muss, würde ich nicht mehr von Unit-Tests sprechen.

 

[maki]

nillehammer, ohne mocks hat man meist keine echten unittests 😉

 

[nillehammer]

nillehammer, ohne mocks hat man meist keine echten unittests

Das stimmt natürlich. Aber ich habe die immer als Einfachst-Implementierungen einer Schnittstelle gesehen, die die zu testende Unit bedient/benutzt. So "magisches" Zeugs wie Methodenaufrufe zu erfassen habe ich nie als deren Aufgabe angesehen. Aber vielleicht fasse ich auch den Begriff "Mock" zu eng. Auf jeden Fall sollte ich mich wohl mal mit Mockito etwas näher befassen.

 

[bygones]

Vielleicht fasse ich den Begriff "Unit-Test" etwas zu eng, aber wenn ich externe Werkzeuge benutzen muss, würde ich nicht mehr von Unit-Tests sprechen.

Ein Unit Test heisst einfach du testest eine Einheit abgekoppelt von deren Abhaengigkeiten. Wenn du es schaffst durch einfach Instanzierung oder Dummy implementierungen diese Entkoppelung zu erreichen - hervorragend.
Bei allem anderen kommen dann mock frameworke ins spiel, weil man eben ansonsten nicht mehr units testen kann.

mocks an sich testen auch nicht methoden aufrufe, manche frameworks koennen das eben.