# JUnit: Testen ob bestimmte Exception nicht auftritt



## aze (20. Dez 2011)

Hi

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

Schöne Grüße

Aze


----------



## bygones (20. Dez 2011)

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

was machst du mit der Exception ansich - einfach schlucken ?


----------



## aze (20. Dez 2011)

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 (20. Dez 2011)

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


----------



## tfa (20. Dez 2011)

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


----------



## aze (20. Dez 2011)

tfa hat gesagt.:


> 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 (20. Dez 2011)

```
try {
    // ...
catch (MySecurityException e) {
   fail("this should not happen");
}
```
Aber das macht wirklich kein Sinn...


----------



## bygones (20. Dez 2011)

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 (20. Dez 2011)

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 (20. Dez 2011)

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


----------



## aze (20. Dez 2011)

tfa hat gesagt.:


> 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 (20. Dez 2011)

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 (20. Dez 2011)

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 (20. Dez 2011)

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


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


----------



## bygones (20. Dez 2011)

nillehammer hat gesagt.:


> . 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 (21. Dez 2011)

tfa hat gesagt.:
			
		

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


			
				bygones hat gesagt.:
			
		

> 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 (21. Dez 2011)

nillehammer, ohne mocks hat man meist keine echten unittests


----------



## nillehammer (21. Dez 2011)

> 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 (21. Dez 2011)

nillehammer hat gesagt.:


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


----------

