Testfälle bei Java ( Junit-Test)

[Wirtschaftsinformatiker]

Moin, ich habe eine allgemeine Frage zum Thema Junit-Test bei Java. Es wäre sehr nett, wenn jemand mir hilft.

Wie könnte die Test-Methode aussehen, damit sie Ihnen wirklich hilft, Fehler in den Methoden zu finden? Wie wählen Sie die Testfälle aus? Was passiert, wenn ein Test fehlschlägt?

 

[Robert Zenz]

Also rein technisch gesehen sollte man jede Permutation der Parameter einen Testfall haben. Da das bei long etwas langweilig ist, sollte man versuchen die gesamte Logik der Methode abzudecken, also alle Zweige welche durchlaufen werden.

Nehmen wir mal folgende Methode an:

public static int calc(int firstValue, int secondValue) {
    if (secondValue < 0) {
        throw new IllegalArgumentException(String.format("\"secondValue\" darf nicht negativ sein, war aber <%d>.",
                Integer.valueOf(secondValue)));
    }

    if (firstValue < 0) {
       return secondValue - firstValue;
    }
    
    return firstValue - secondValue;
}

Aus der Luft gegriffen, versteht sich. Wenn wir dafuer jetzt einen Test schreiben:

@Test
public void testCalc() {
    Assertions.assertEquals(-2, ThatClass.calc(5, 7));
}

Damit haben wir jetzt einen Test fuer die "Basis-Funktion" der Funktion, aber wir haben nicht alle Zweige abgedeckt. Dafuer brauchen wir dann weitere Tests:

@Test
public void testCalc() {
    Assertions.assertEquals(-2, ThatClass.calc(5, 7));
}

@Test
public void testCalcIllegalSecondValue() {
    try {
        ThatClass.calc(5, -7);
        
        Assertions.fail("Methode sollte mit einer IllegalStateException fehlschlagen, ist sie aber nicht.");
    } catch (IllegalStateException e) {
        if (!e.getMessage().equals("\"secondValue\" darf nicht negativ sein, war aber <-7>.")) {
            throw e;
        }
    }
}

@Test
public void testCalcNegativeFirstValue() {
    Assertions.assertEquals(12, ThatClass.calc(-5, 7));
}

Damit haben wir dann alle Zweige in dieser Funktion abgedeckt.

Was passiert, wenn ein Test fehlschlägt?

Man repariert entweder die Funktion oder den Test.

 

[KonradN]

Evtl. ist die Frage

Was passiert, wenn ein Test fehlschlägt?

mehr technisch gemeint?

Wenn die Tests bestandteil des Build Prozesses sind, dann bricht der Build Prozess in der Regel ab (So Fehler nicht ignoriert werden sollen). Das bedeutet, dass die nachfolgenden Schritte wie das Bauen von irgendwelchen Paketen, das Deployen zu irgendwelchen Zielen u.s.w. nicht weiter statt findet (Macht ja auch wenig Sinn. Tests, die fehlschlagen, zeigen ja auf, dass es Fehler gibt)!

Wenn es nur in der Entwicklungsumgebung lief, dann bekommt man eine Auswertung. Dies kann in Form von Text erfolgen oder aufbereitet mit Grafiken/Farben. Also im einfachsten Fall etwas wie: "x Testfälle durchgeführt, y Testfälle erfolgreich, z Textfälle fehlerhaft."

 

[LimDul]

Bzgl, wie soll eine Test-Methode aussehen, dass sie hilft. Da gibt es verschiedene Aspekte.

Lesbarkeit
Ein Test, der nicht lesbar ist, hilft nichts im Fehlerfall. Weil dann versteht man nicht ist der Test falsch oder hab ich was kaputt gemacht. Das heißt an einen Test gelten ähnliche Anforderungen wie an Produktiv-Code. Er sollte verständlich sein, möglichst Duplikatsfrei etc. Konstanten/Werte sollten sinnvoll benannt sein

Vollständigkeit
Wie testet man alle Konstellation ab? Hier gibt es zwei Dinge, die man im Kopf haben sollte.

a) Äquivalenzklassen. Man kann oft nicht alle Eingaben testen. Das heißt, man bildet Äquivalenzklassen von Werten, die fachlich und technisch identisch sein sollten. Und dann nimmt man einen Vertreter (oder drei - untere Grenze, obere Grenze, mitten Drin) daraus und testet das Verhalten für die ab. Wie man die findet, hängt von der zu testenden Funktion ab. Bei Zahlen bietet es sich an immer mindest drei Äquivalenzklassen zu haben - kleiner 0, gleich 0 und größer 0. Können aber auch mehr sein.

b) Fehlerhafte Eingaben
Man neigt bei Testfällen oft dazu sich auf die Werte zu fokussieren, wo sich die Methode sinnvoll verhält. Fast noch wichtiger sind aber die Aufrufe, die nicht ok sind. Das ist oft null, Leerstrings oder ähnliches. Auch für diese Eingaben sollte eine Funktion ein definiertes Verhalten zeigen (Was durchaus eine Exception sein kann). Die sollten daher auch getestet werden.