Test auf Exceptions schreiben

[Mariexshhx]

@Test
void test_divideByZero() {
    Executable code = new Executable() {
        public void execute() throws Throwable {
            Division.div(2, 0);
        }
    };
    ArithmeticException exception = assertThrows(ArithmeticException.class,
            code);
    assertThat(exception.getMessage()).contains("by zero");
}

wieso muss der Methodenaufruf bei testen auf eine Exception in ein executable Objekt gespeichert werden ?

alos wieso reicht nicht der alleinige Methodenaufruf ?

@Test
void test_divideByZero() {
    ArithmeticException exception = assertThrows(ArithmeticException.class,
            Division.div(2, 0););
    assertThat(exception.getMessage()).contains("by zero");
}

 

[KonradN]

Bei deiner zweiten Variante würde assertThrows mit dem Ergebnis des Aufrufes ausgeführt. Das willst Du aber nicht, denn
1. gibt die Methode kein Executable zurück (Und das ist der Typ des zweiten Parameters)
2. würde die Exception bei der Evaluierung der Parameter geworfen ...

Sinn ist es ja, dass das, was ausgeführt werden soll, erst von der assertThrows Methode aufgerufen wird.

Was man hier hat ist also ganz einfach verallgemeinert:
Die Methode assertThrows erwartet ein Parameter der vom Typ eines funktionalen Interfaces ist, damit kann diese Methode aufgerufen werden:
a) mit einer Instanz des Interfaces (was Dein Code macht)
b) mit einer Lambda Expression, also etwas wie () -> Division.div(2,0)
c) mit einer Methodenreferenz

Das wäre so die Java Sicht auf das, was da gemacht wird bzw gemacht werden kann.

 

[LimDul]

Das wird so ggf. nicht kompilieren und funktionieren.
Wenn div eine checked Exception wirft, muss du sie entweder fangen oder weiterwerfen. Dein zweiter Code macht gar nichts davon. die assertThrows Methode bekommt die Exception nie zu sehen.

Java ruft Division.div(2,0) auf um den Rückgabewert in die Methode assertThrows zu stecken. Nur leider gibt die Methode nichts zurück, sondern wirft eine Exception. Damit greift das Exception-Handling, assertThrows wird nie aufgerufen und da es keinen catch Block gibt, wird die Exception weitergeworfen.

 

[Mariexshhx]

achso deswegen muss quasi die Exception einem einem Executable gespeichert werden damit man mit der Exception dann die assertThrow Methode aufruft ?

Das wird so ggf. nicht kompilieren und funktionieren.
Wenn div eine checked Exception wirft, muss du sie entweder fangen oder weiterwerfen. Dein zweiter Code macht gar nichts davon. die assertThrows Methode bekommt die Exception nie zu sehen.

Java ruft Division.div(2,0) auf um den Rückgabewert in die Methode assertThrows zu stecken. Nur leider gibt die Methode nichts zurück, sondern wirft eine Exception. Damit greift das Exception-Handling, assertThrows wird nie aufgerufen und da es keinen catch Block gibt, wird die Exception weitergeworfen.

 

[Mariexshhx]

Bei deiner zweiten Variante würde assertThrows mit dem Ergebnis des Aufrufes ausgeführt. Das willst Du aber nicht, denn
1. gibt die Methode kein Executable zurück (Und das ist der Typ des zweiten Parameters)
2. würde die Exception bei der Evaluierung der Parameter geworfen ...

Sinn ist es ja, dass das, was ausgeführt werden soll, erst von der assertThrows Methode aufgerufen wird.

Was man hier hat ist also ganz einfach verallgemeinert:
Die Methode assertThrows erwartet ein Parameter der vom Typ eines funktionalen Interfaces ist, damit kann diese Methode aufgerufen werden:
a) mit einer Instanz des Interfaces (was Dein Code macht)
b) mit einer Lambda Expression, also etwas wie () -> Division.div(2,0)
c) mit einer Methodenreferenz

Das wäre so die Java Sicht auf das, was da gemacht wird bzw gemacht werden kann.

wenn assertThrow bei dem zweiten Beispiel nie aufgerufen wird, was steckt denn dann aber in der Variablen exception ?

 

[KonradN]

wenn assertThrow bei dem zweiten Beispiel nie aufgerufen wird, was steckt denn dann aber in der Variablen exception ?

Da die Auswertung des zweiten Parameters eine Exception wirft, wird assertThrows nicht aufgerufen und exception wird nichts zugewiesen. Die Ausführung endet an der Stelle, an der die Exception geworfen wurde und dann geht es den Stacktrace zurück bis entweder die Exception behandelt wurde oder eben der Thread endet.

 

[Mariexshhx]

Da die Auswertung des zweiten Parameters eine Exception wirft, wird assertThrows nicht aufgerufen und exception wird nichts zugewiesen. Die Ausführung endet an der Stelle, an der die Exception geworfen wurde und dann geht es den Stacktrace zurück bis entweder die Exception behandelt wurde oder eben der Thread endet.

und was genau macht die execute Methode dagegen vezögert sie das Werfen der Exception oder wie genau?

 

[KonradN]

Die execute Methode ruft ja einfach nur den Code auf, der die erwartete Exception auslösen soll.

assertThrows macht also unter dem Strich etwas wie (stark vereinfacht):

Exception assertThrows(Class exceptionClass, Executable executable) {
    try {
        executable.execute();
        fail();
    } catch (Exception ex) {
        assertTrue(exceptionClass.isInstance(ex)); // stark vereinfacht.
        return ex;
    }
}

Es wird also ausgeführt und die Exception gefangen. Wenn keine Exception geworfen wurde, dann ist der Test fehlgeschlagen. Und wenn eine Exception geworfen wurde, dann wird der Typ geprüft. Stark vereinfacht und das würde so nicht übersetzen .. aber es wird hoffentlich deutlich, was dieses assertThrows macht.

 

[Mariexshhx]

Die execute Methode ruft ja einfach nur den Code auf, der die erwartete Exception auslösen soll.

assertThrows macht also unter dem Strich etwas wie (stark vereinfacht):

Exception assertThrows(Class exceptionClass, Executable executable) {
    try {
        executable.execute();
        fail();
    } catch (Exception ex) {
        assertTrue(exceptionClass.isInstance(ex)); // stark vereinfacht.
        return ex;
    }
}

Es wird also ausgeführt und die Exception gefangen. Wenn keine Exception geworfen wurde, dann ist der Test fehlgeschlagen. Und wenn eine Exception geworfen wurde, dann wird der Typ geprüft. Stark vereinfacht und das würde so nicht übersetzen .. aber es wird hoffentlich deutlich, was dieses assertThrows macht.

assertThrow prüft dann also den Typen der Exception falls es eine gibt ?

 

[KonradN]

Ja, der Typ wird auch geprüft.

Wenn unklar ist, was so Methoden machen: ggf hilft da die Dokumentation:

Assertions (JUnit 5.8.1 API)

declaration: module: org.junit.jupiter.api, package: org.junit.jupiter.api, class: Assertions

junit.org

 

[Mariexshhx]

Ja, der Typ wird auch geprüft.

Wenn unklar ist, was so Methoden machen: ggf hilft da die Dokumentation:

Assertions (JUnit 5.8.1 API)

declaration: module: org.junit.jupiter.api, package: org.junit.jupiter.api, class: Assertions

junit.org

okay danke ich hatte gelernt, dass sie die Exception zurückgibt

 

[KonradN]

okay danke ich hatte gelernt, dass sie die Exception zurückgibt

Auch, der Typ wird aber schon geprüft. Aber man will ja ggf. noch die Meldung prüfen oder so. Daher die Möglichkeit, da noch mehr zu prüfen.