# JUnit testen ob keine Exception auftritt



## turmaline (10. Dez 2010)

Hallo Leute,

mit der fail()-Methode der Assert-API kann man abtesten ob ein Aufruf fehlschläft. Wie kann ich das gegenteil abtesten: also dass während der Ausführung einer konkreten Methode keine Exception geworfen wird.. Es muss nichts mehr abgetestet werden. Die Methode liefert auch ncihts zurück.

Vielen Dank im Voraus,

madlena


----------



## maki (10. Dez 2010)

Dann einfach nur die zu testenden Objekte/Methoden "exerzieren", wenn eine Exception fliegt gilt der Test als nicht bestanden.


----------



## tfa (10. Dez 2010)

Wenn in der Testmethode eine Exception fliegt, ist der Test automatisch fehl geschlagen. Du musst nichts weiter tun.


----------



## bygones (10. Dez 2010)

schwieriger wirds nur dann, wenn der zu testende Code die Exception abfängt und gütig weitermacht. Dann ists nicht einfach überprüfbar ob diese Exception geworfen wurde.

Ich hoffe mal das ist aber schon gar nicht der Fall, daher siehe die beiden Antworten oben


----------



## turmaline (10. Dez 2010)

tfa hat gesagt.:


> Wenn in der Testmethode eine Exception fliegt, ist der Test automatisch fehl geschlagen. Du musst nichts weiter tun.



ich finde es aber dass es kein guter Stil ist, wenn eine Testmethode keine assert-Methode hat. So wie jetzt (also ich habe den Test übernommen). Gut ich prüfe nun die Auswirkungen des Aufrufes.

Gruß,
madlena


----------



## maki (10. Dez 2010)

turmaline hat gesagt.:


> ich finde es aber dass es kein guter Stil ist, wenn eine Testmethode keine assert-Methode hat. So wie jetzt (also ich habe den Test übernommen). Gut ich prüfe nun die Auswirkungen des Aufrufes.


Das ist so falsch, mit Mockobjekten zB. braucht man auch kaum (wenn überhaupt) noch asserts, ausserdem ist eine unerwartete Exception generell ein Fehler in JUnit, oder würdest du lieber asserts schreiben für jede mögliche & unmögliche Exception die auftreten kann?


----------



## Gast2 (10. Dez 2010)

Naja... du kannst halt es wrappen:

```
boolean exceptionThrown = false;
try{
    myMethod();
  } catch (Exception e) {
    exceptionThrown = true;
  }
assert !exceptionThrown;
```

Aber ob das mehr Sinn macht oder guter Stil ist?


----------



## tfa (10. Dez 2010)

> ich finde es aber dass es kein guter Stil ist, wenn eine Testmethode keine assert-Methode hat.


Was musst du denn inhaltlich prüfen? Ich meine, was ist die Nachbedingung der Methode? Nur, dass keine Exception fliegt? Ein bisschen wenig.


----------



## bygones (10. Dez 2010)

fassy hat gesagt.:


> Naja... du kannst halt es wrappen:
> 
> ```
> boolean exceptionThrown = false;
> ...


nein...

wenn du explizit eine Exception erwartest dann kannst du das über @Test(expected=IndexOutOfBoundsException.class) annotieren (was aber auch gefährlich ist...).

wenn du keine erwartest, dann brauchst du auch keine logik erstellen, denn wie schon gesagt -> exception == gescheiterter Test.

@topic:
Ohne Mockobjekte sollten asserts in der Methode vorkommen... ja. Das reine Testen ob eine Exception aufkommt ist, wie gesagt, fraglich.
Sobald man mit Mockobkjekten und deren Verhalten arbeitet, so weniger asserts hat man auch und das ist auch gut so ;-)


----------



## Gast2 (10. Dez 2010)

bygones hat gesagt.:


> nein...
> 
> wenn du explizit eine Exception erwartest dann kannst du das über @Test(expected=IndexOutOfBoundsException.class) annotieren (was aber auch gefährlich ist...).



Ich empfehle es ja auch nicht! Sondern sage es ist eine Möglichkeit - die ich nicht für sinnvoll und elegant halte...


----------



## turmaline (10. Dez 2010)

hm.. die tests sollen eigentlich prüfen ob die aufrufe KIENE Exception verursachen.
schreibt ihr auch solche tests ohne assert-Methoden?


----------



## maki (10. Dez 2010)

turmaline hat gesagt.:


> hm.. die tests sollen eigentlich prüfen ob die aufrufe KIENE Exception verursachen.
> schreibt ihr auch solche tests ohne assert-Methoden?


Solche tests schreibe ich ehrlich gesagt nie, die sind nicht aussagekräftig/nutzlos und daher Zeitverschwendung.

Tests prüfen ob bestimmte Dinge funktionieren, alles andere (Exceptions etc.) bedeutet dass sie nicht funktinieren -> Test fehlgeschlagen


----------



## bygones (10. Dez 2010)

turmaline hat gesagt.:


> hm.. die tests sollen eigentlich prüfen ob die aufrufe KIENE Exception verursachen.
> schreibt ihr auch solche tests ohne assert-Methoden?


ich würde einen Test schreiben der überprüft dass die Methode a) das tut was sie tun soll bzw b) dass ds zurückkommt was zurückkommen soll.
Fliegt eine Exception, so gilt der Test auch als fehlgeschlagen. Ergo keine Exception + Überprüfung => erfolgreicher Test.

also somit ist die überprüfung, dass KEINE exception geworfen wurde in einem "normalen" Test schon inkludiert.

Ausnahme: siehe meinen ersten Beitrag


----------



## turmaline (10. Dez 2010)

alles klar. wie ich oben schon geschrieben habe, ich erweitere die Test-Methoden gerade und prüfe ob bestimmte Dinge passieren, die passieren sollen (das meinte ich mit Auswirklungen eines Aufrufes, vielleicht wurde ich falsch verstanden??).

dake für die Antworten!


----------



## Gast2 (10. Dez 2010)

Also du willst testen ob auch wirklich eine Exception fliegt wenn du ein bestimmte Parameter übergibst? Dann könntest du das so machen wie ich oben gemacht habe oder über die Annotation wie bygones gesagt hat. Die Frage ist was du überhaupt testen möchtest?

Um möglichst gute Testabdeckung zu erreichen bietet es sich an Coverage Tools wie z.B. Cobertura zusätzlich zu verwenden.


----------



## turmaline (10. Dez 2010)

die intension dieser tests war und bleibt, zu überprüfen, ob ein bestimmter methodenaufruf normal funktioniert und keine exce geworfen werden (das habe ich bereits oben geschrieben).

Beispiel:


```
@Test
    public void test() throws Exception {
        _syncClient.getLastFeedbackSyncDate(USER);
    }
```

Für mich ergeben solche tests nicht so viel sinn, deswegen schriebe ich nun so:


```
@Test
    public void test() throws Exception {
        assertNotNull(_syncClient.getLastFeedbackSyncDate(USER));
    }
```


----------



## turmaline (10. Dez 2010)

sprechen wir alle Deutsch oder warum versteht mich hier keiner?


----------



## Gast2 (10. Dez 2010)

Ja, ist doch gut so? Wo ist denn jetzt ein Problem?


----------



## turmaline (10. Dez 2010)

es gibt keins :-D


----------



## maki (10. Dez 2010)

turmaline hat gesagt.:


> sprechen wir alle Deutsch oder warum versteht mich hier keiner?


Das Missverständniss ist ganz auf deiner Seite 

Nebenbei, ein assertNotNull wäre mir nicht gut genug für diesen Test


----------



## turmaline (10. Dez 2010)

das glaube ich nicht dass das misverständnis auf meiner seite ist, aber es ist völlig egal. es wäre mir jetzt komplizierter das zu "beweisen", als es sein zu lassen 

was wäre für Dich "gut genug" für diesen Test?


----------



## Gast2 (10. Dez 2010)

Das Objekt was aus der Methode zurückgegeben wird noch untersuchen ob es dem entspricht was erwartet wird.


----------



## maki (10. Dez 2010)

turmaline hat gesagt.:


> was wäre für Dich "gut genug" für diesen Test?


zB. ein Test der ein bekanntes Ergebnis erwartet und darauf prüft, "nicht null" kann eben alles ausser null sein, dass ist aber selten richtig


----------



## turmaline (10. Dez 2010)

das stimmt würde ich im normallfall auch tun, da aber es gar nicht untersucht werden soll (frag mich nicht warum), begnüge ich mich mit einfachem assertNotNull


----------

