JUnit testen ob keine Exception auftritt

[turmaline]

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]

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

 

[tfa]

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

 

[bygones]

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]

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]

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]

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]

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]

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?

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]

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]

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

 

[maki]

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]

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]

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]

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]

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]

sprechen wir alle Deutsch oder warum versteht mich hier keiner?

 

[Gast2]

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

 

[turmaline]

es gibt keins :-D

 

[maki]

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]

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]

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

 

[maki]

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]

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