White-Box-Testing mit JUnit: So meisterst du CS6300 Assignment 6

White-Box-Testing mit JUnit: Dein Leitfaden für CS6300 Assignment 6

White-Box-Testing (auch Strukturtest genannt) ist eine zentrale Technik im Softwaretest. Anders als beim Black-Box-Testing kennst du als Tester den Quellcode und kannst Tests gezielt auf Zweige, Pfade und Bedingungen ausrichten. Im CS6300 Assignment 6 (Fall 2025) geht es genau darum: Du erhältst fehlerhafte Methoden wie defectMethod4 und defectMethod5 und musst JUnit-Testklassen schreiben, die die Fehler aufdecken. Klingt nach einer typischen Aufgabe im Software Engineering Studium? Richtig! Und genau dafür ist dieser Tutorial gedacht.

Was ist White-Box-Testing?

Beim White-Box-Testing analysierst du den Code zeilenweise. Du prüfst, ob alle Zweige (if-else) durchlaufen werden, ob Schleifen korrekt terminieren und ob Bedingungen wie (c == 0) && ((d > 0) || (e < 0)) vollständig getestet sind. Ein bekanntes Maß ist die Zweigüberdeckung (branch coverage): Jeder mögliche Zweig muss mindestens einmal ausgeführt werden.

Stell dir vor, du testest eine KI-gestützte Empfehlungs-App für Musik. Der Code entscheidet, ob ein Song vorgeschlagen wird – basierend auf Genre, Stimmung und Hörverhalten. Mit White-Box-Tests stellst du sicher, dass jede Kombination (z. B. „traurig + Rock“ oder „fröhlich + Pop“) getestet wird. Genauso gehst du bei defectMethod4 vor.

Die Methoden aus Assignment 6 verstehen

Die erste Methode defectMethod4 hat die Signatur:

public static int defectMethod4(boolean a, boolean b, int c, int d, int e) {
    int result = 0;
    if (a == b) {
        result = 1;
    } else {
        if ((c == 0) && ((d > 0) || (e < 0))) {
            result = 2;
        } else {
            result = 3;
        }
    }
    return result;
}

Die Methode gibt 1, 2 oder 3 zurück. Ein Fehler könnte z. B. sein, dass result = 1 nie erreicht wird, weil a == b immer falsch ist. Oder die Bedingung (c == 0) && ((d > 0) || (e < 0)) ist fehlerhaft geschrieben – vielleicht fehlt eine Klammer oder ein Operator.

Die zweite Methode defectMethod5 ist kniffliger:

public static boolean defectMethod5(boolean a, boolean b) {
    int x = 3;
    int y = 1;
    if(a) {
        x += y;
    } else {
        y = y * x;
    }
    if(b) {
        y -= x;
    } else {
        y -= 1;
    }
    return ((x / y) >= 0);
}

Hier könnte eine Division durch Null auftreten, wenn y = 0 wird. Oder der Rückgabewert ist immer true, obwohl er false sein sollte. Deine JUnit-Tests müssen solche Fälle abdecken.

JUnit-Tests schreiben – Schritt für Schritt

Für CS6300 Assignment 6 musst du zwei Testklassen erstellen, die jeweils defectMethod4 bzw. defectMethod5 aufrufen. Jeder Testfall ruft die Methode genau einmal auf. Das Ziel: Die Fehler in den Methoden aufdecken.

Ein typischer JUnit-Test sieht so aus:

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

public class DefectMethod4Test {
    @Test
    public void testAEqualsB() {
        assertEquals(1, defectMethod4(true, true, 0, 1, -1));
    }
    
    @Test
    public void testCZeroAndDPositive() {
        assertEquals(2, defectMethod4(true, false, 0, 5, 1));
    }
    
    @Test
    public void testCZeroAndENegative() {
        assertEquals(2, defectMethod4(true, false, 0, -1, -5));
    }
    
    @Test
    public void testElseBranch() {
        assertEquals(3, defectMethod4(true, false, 1, 0, 0));
    }
}

Beachte: Die erwarteten Ergebnisse musst du aus dem Code ableiten. Wenn die Methode einen Fehler hat, stimmt das tatsächliche Ergebnis nicht mit dem erwarteten überein – und der Test schlägt fehl. Genau das willst du: Fehler erkennen.

Zweigüberdeckung und Pfadüberdeckung

Um sicherzustellen, dass du alle Zweige testest, reicht es nicht, nur einige Werte zu probieren. Du musst systematisch vorgehen:

• Zweigüberdeckung: Jede if-else-Entscheidung muss beide Ausgänge durchlaufen. Für defectMethod4 gibt es zwei if-Statements – also mindestens 4 Testfälle (a==b true/false, innere Bedingung true/false).
• Pfadüberdeckung: Jeder mögliche Pfad durch den Code. Bei defectMethod4 gibt es 3 Pfade (a==b → result=1; a!=b und Bedingung wahr → result=2; a!=b und Bedingung falsch → result=3).

Ein Trend-Beispiel: Stell dir vor, du testest die Login-Funktion einer Finanz-App. Der Code prüft zuerst, ob der Benutzer existiert (if), dann ob das Passwort korrekt ist (if). Mit White-Box-Tests stellst du sicher, dass alle Kombinationen getestet werden: Benutzer existiert / existiert nicht, Passwort richtig / falsch. Genauso gehst du bei defectMethod5 vor: Hier gibt es zwei if-Statements hintereinander – das ergibt 4 Pfade (a true/false × b true/false).

Häufige Fehler und Fallstricke

In CS6300 Assignment 6 gibt es einige Notes, die du beachten musst:

• Verbotene Konstrukte: Du darfst keine Schleifen, Rekursion oder bestimmte Bibliotheken verwenden. Halte dich genau an die Vorgaben, sonst gibt es 0 Punkte.
• Gradescope-Checks: Deine Abgabe wird automatisch geprüft. Stelle sicher, dass die Dateien im richtigen Verzeichnis liegen und die Testklassen kompilieren.
• Sanity Checks: Selbst wenn deine Tests alle Fehler finden, musst du die Sanity Checks bestehen. Das bedeutet: Deine Tests müssen die erwartete Struktur haben (z. B. genau ein Aufruf pro Testmethode).

Ein häufiger Fehler ist, dass Testfälle nicht unabhängig sind. Jeder Test sollte eine eindeutige Kombination von Eingabewerten verwenden. Vermeide es, denselben Test mehrfach auszuführen – das bringt keine neue Überdeckung.

Praktische Tipps für die Abgabe

1. Verstehe den Code: Analysiere defectMethod4 und defectMethod5 genau. Zeichne ein Kontrollflussdiagramm, um alle Pfade zu sehen.
2. Erstelle Testfälle systematisch: Nutze eine Tabelle mit Eingabewerten und erwarteten Ergebnissen. Für defectMethod5 berechne x und y nach jedem Schritt – so vermeidest du Überraschungen.
3. Teste auch Randfälle: Bei defectMethod5 ist y = 0 ein kritischer Fall. Wenn du a = false und b = true wählst, wird y = 3 (aus else-Zweig) und dann y -= x → y = 0. Division durch Null! Dein Test sollte eine ArithmeticException erwarten oder abfangen.
4. Nutze JUnit 5: Die Aufgabenstellung verwendet org.junit.platform.console.ConsoleLauncher – das ist JUnit 5. Verwende @Test aus org.junit.jupiter.api.
5. Dokumentiere deine Tests: Füge Kommentare hinzu, welchen Zweig oder Pfad du testest. Das hilft dir und den Korrektoren.

Beispiel für defectMethod5-Tests

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

public class DefectMethod5Test {
    // Pfad: a=true, b=true -> x=4, y=0 -> Division durch Null?
    @Test
    public void testATrueBTrue() {
        assertThrows(ArithmeticException.class, () -> {
            defectMethod5(true, true);
        });
    }
    
    // Pfad: a=true, b=false -> x=4, y=0 -> Division durch Null?
    @Test
    public void testATrueBFalse() {
        assertThrows(ArithmeticException.class, () -> {
            defectMethod5(true, false);
        });
    }
    
    // Pfad: a=false, b=true -> x=3, y=3 -> dann y=0 -> Division durch Null?
    @Test
    public void testAFalseBTrue() {
        assertThrows(ArithmeticException.class, () -> {
            defectMethod5(false, true);
        });
    }
    
    // Pfad: a=false, b=false -> x=3, y=3 -> dann y=2 -> Ergebnis true
    @Test
    public void testAFalseBFalse() {
        assertTrue(defectMethod5(false, false));
    }
}

In diesem Beispiel wird deutlich, dass drei der vier Pfade zu einer Division durch Null führen – ein klarer Fehler in der Methode. Deine Aufgabe ist es, solche Fehler durch gezielte White-Box-Tests aufzudecken.

Fazit

White-Box-Testing ist eine mächtige Technik, um Fehler im Code zu finden. Mit JUnit und systematischen Tests erreichst du eine hohe Zweig- und Pfadüberdeckung. Für CS6300 Assignment 6 ist es entscheidend, die Methoden genau zu verstehen und Tests zu schreiben, die die Fehler provozieren. Nutze die Hinweise aus diesem Tutorial, um deine Tests zu optimieren und die Gradescope-Checks zu bestehen. Viel Erfolg!