JUnit in Java - was du wirklich testen solltest

JUnit gehört in Java-Projekten zu den Werkzeugen, die du früher oder später sowieso brauchst. Nicht, weil Tests gut klingen oder weil es in Tutorials oft so gemacht wird, sondern weil du mit Tests prüfen kannst, ob dein Code das tut, was du erwartest. Genau da liegt der eigentliche Wert. Ein Test ist kein Selbstzweck. Er gibt dir Sicherheit bei Änderungen, hilft dir beim Verstehen von Logik und macht Fehler sichtbar, bevor sie an einer anderen Stelle im Projekt auftauchen.

Wenn du schon einmal eine Methode geschrieben, gestartet und dann mit ein paar System.out.println() geprüft hast, ob das Ergebnis passt, dann hast du im Grunde bereits manuell getestet. JUnit macht daraus einen wiederholbaren, sauberen und automatisierten Ablauf. Du schreibst also nicht nur Code, der etwas erledigt, sondern auch Code, der überprüft, ob dieses Verhalten stabil bleibt.

Der wichtige Punkt dabei ist: JUnit testet nicht "irgendwie alles", sondern immer ganz konkret Verhalten. Du formulierst eine Erwartung, führst Code aus und prüfst das Ergebnis. Genau deshalb funktionieren gute Tests am besten bei klaren Eingaben und klaren Ausgaben.

Was JUnit eigentlich ist und wofür du es einsetzt

JUnit ist ein Testframework für Java. Damit schreibst und startest du automatisierte Tests direkt für deinen Code. Ein Testfall ist meist eine kleine Methode, die genau eine fachliche oder technische Erwartung überprüft. Du testest also nicht, ob dein Projekt schön strukturiert ist, sondern ob zum Beispiel eine Berechnung korrekt läuft, ob eine Ausnahme geworfen wird oder ob ein bestimmter Rückgabewert entsteht.

Ein sehr einfacher Test kann so aussehen:

@Test
void shouldAddTwoNumbers() {
    int result = 2 + 3;
    assertEquals(5, result);
}

Das Beispiel ist klein, zeigt aber das Grundprinzip. Es gibt einen Ausgangspunkt, eine Aktion und eine Erwartung. Genau so solltest du Tests gedanklich auch lesen. Was ist gegeben, was passiert, was soll am Ende herauskommen.

Mit JUnit kannst du deutlich mehr als nur assertEquals verwenden. Du kannst prüfen, ob etwas null oder nicht null ist, ob eine Ausnahme geworfen wird, ob ein boolean true oder false ist oder ob mehrere Bedingungen zusammen erfüllt sind. Dazu kommen Dinge wie Setup-Methoden, die vor jedem Test laufen, parameterisierte Tests mit mehreren Eingabewerten oder eine saubere Gruppierung von Tests.

Wichtig ist aber auch, was JUnit allein nicht ist. JUnit ist kein Mocking-Framework, keine Datenbank-Simulation und kein Werkzeug, das dir automatisch gute Testfälle ausdenkt. Es ist die Grundlage, auf der du Tests formulierst und ausführst. Für Abhängigkeiten wie HTTP-Clients, Datenbanken oder externe Services brauchst du oft zusätzliche Werkzeuge oder Teststrategien.

Was du mit JUnit testen solltest und wo die Grenzen liegen

Am einfachsten testest du Logik, die klar abgegrenzt ist. Das sind zum Beispiel Berechnungen, Validierungen, Umwandlungen von Daten, String-Verarbeitung, Datumslogik oder fachliche Regeln. Wenn eine Methode einen klaren Input bekommt und ein klar erwartbares Ergebnis liefert, ist sie fast immer ein guter Kandidat für einen Unit-Test.

Nehmen wir eine kleine Methode zur Rabattberechnung:

public double calculatePrice(double price, double discountInPercent) {
    return price - (price * discountInPercent / 100);
}

Dafür lässt sich ein sinnvoller Test schreiben:

@Test
void shouldCalculateDiscountedPrice() {
    double result = calculatePrice(100.0, 20.0);
    assertEquals(80.0, result);
}

Spannend wird es bei Randfällen. Was passiert bei 0 Prozent Rabatt, bei 100 Prozent oder bei negativen Werten. Genau solche Fälle sind oft wertvoller als der offensichtliche Standardfall, weil dort Fehler besonders gern entstehen.

Schwieriger wird es, wenn dein Code stark von seiner Umgebung abhängt. Ein Beispiel wäre eine Methode, die direkt auf eine Datenbank schreibt, ein REST-System aufruft, die Uhrzeit des Systems verwendet oder Dateien liest. Solche Dinge kannst du zwar ebenfalls testen, aber nicht immer sinnvoll als einfachen Unit-Test. Dann bewegst du dich eher in Richtung Integrationstest. Der prüft nicht nur eine isolierte Methode, sondern das Zusammenspiel mehrerer Teile.

Hier ist eine wichtige Grenze: Ein einfacher JUnit-Test ist nicht dafür gedacht, die komplette Anwendung realistisch von vorne bis hinten zu simulieren. Er ersetzt keinen End-to-End-Test, keine manuelle UX-Prüfung und keine Lasttests. Auch das Frontend-Verhalten in einem Browser oder das echte Zusammenspiel mit produktionsnaher Infrastruktur testest du nicht einfach mit einem kleinen JUnit-Test im Java-Modul.

Du kannst mit JUnit also sehr gut einzelne Klassen und Komponenten prüfen. Du kannst auch Integrationen testen, wenn die Umgebung dafür vorbereitet ist. Aber JUnit allein ist nicht das richtige Werkzeug für alles. Gerade bei Performance, echtem Benutzerverhalten oder komplexen Systemlandschaften brauchst du andere Testarten zusätzlich.

Wie du gute JUnit-Tests schreibst und welche Test-Typen du kennen solltest

Ein guter Test ist klar, klein und stabil. Wenn du beim Lesen eines Tests erst drei Minuten überlegen musst, was eigentlich geprüft wird, ist der Test meistens zu kompliziert. Gute Tests haben einen erkennbaren Fokus. Sie prüfen genau ein Verhalten und machen im Fehlerfall schnell sichtbar, was kaputt ist.

In vielen Projekten hilft dabei die Struktur Arrange, Act, Assert. Du bereitest Daten vor, führst die eigentliche Aktion aus und prüfst danach das Ergebnis. Das muss nicht ausgeschrieben im Code stehen, aber im Kopf ist dieses Muster sehr hilfreich.

Ein Beispiel mit Ausnahmeprüfung sieht so aus:

@Test
void shouldThrowExceptionForNegativeAmount() {
    assertThrows(IllegalArgumentException.class,
            () -> validateAmount(-5));
}

Auch das ist ein sauberer Test, weil die Erwartung glasklar ist. Nicht irgendein Fehler soll passieren, sondern genau eine bestimmte Ausnahme in einer bestimmten Situation.

Bei den Test-Typen solltest du vor allem drei Begriffe sauber auseinanderhalten. Unit-Tests prüfen kleine, isolierte Einheiten wie einzelne Methoden oder Klassen. Sie laufen schnell und sind oft die erste Verteidigungslinie gegen Fehler. Integrationstests prüfen das Zusammenspiel mehrerer Komponenten, zum Beispiel Service, Repository und Datenbank. End-to-End-Tests prüfen komplette Abläufe aus Sicht der Anwendung oder des Nutzers. JUnit ist vor allem im Unit-Test-Bereich zuhause, wird aber auch häufig als technische Basis für Integrationstests verwendet.

Best Practices sind weniger geheimnisvoll, als es am Anfang manchmal wirkt. Teste Verhalten statt Implementierungsdetails. Es ist meistens nicht sinnvoll zu prüfen, ob intern genau drei Methoden aufgerufen wurden, wenn dich fachlich eigentlich nur das Ergebnis interessiert. Schreibe Tests so, dass sie unabhängig voneinander laufen. Ein Test darf nicht voraussetzen, dass ein anderer Test vorher erfolgreich war. Halte Testdaten überschaubar. Wenn du für einen simplen Test erst ein halbes Objektmodell aufbauen musst, stimmt oft etwas am Design oder an der Testvorbereitung nicht.

Außerdem solltest du sprechende Testnamen verwenden. Ein Name wie test1() hilft dir nach zwei Wochen nicht mehr weiter. Ein Name wie shouldReturnEmptyListWhenNoUsersExist() zeigt sofort, was geprüft wird. Genau das spart später Zeit.

JUnit bringt dafür einige nützliche Funktionen mit. Du kannst mit @BeforeEach gemeinsame Vorbereitung ausführen, mit parameterisierten Tests mehrere Eingaben gegen dieselbe Logik laufen lassen und mit @Nested Tests logisch gruppieren. Gerade parameterisierte Tests sind praktisch, wenn du dieselbe Regel mit mehreren Werten prüfen willst, ohne den Testcode unnötig zu kopieren.

Ein kleines Beispiel dafür:

@ParameterizedTest
@ValueSource(strings = {"Max", "Anna", "Chris"})
void shouldAcceptValidNames(String name) {
    assertTrue(isValidName(name));
}

Was du dagegen eher vermeiden solltest: Tests, die zufällige Daten verwenden und mal grün, mal rot laufen. Tests, die von der aktuellen Uhrzeit abhängen. Tests, die auf Netzwerkverbindungen angewiesen sind, obwohl sie eigentlich nur Geschäftslogik prüfen sollen. Solche Tests sind nicht zuverlässig und sorgen schnell dafür, dass man Testergebnisse nicht mehr ernst nimmt.

Fazit

JUnit ist kein optionales Extra, sondern ein sehr praktisches Werkzeug, um Java-Code nachvollziehbar und sicher zu prüfen. Du testest damit vor allem Verhalten, nicht Magie. Gute Tests zeigen dir, ob Regeln, Berechnungen, Validierungen und zentrale Logik wirklich funktionieren. Sie helfen dir auch dann, wenn du später etwas am Code änderst und wissen willst, ob du aus Versehen etwas kaputt gemacht hast.

Wichtig ist, dass du die Grenzen kennst. Nicht alles, was testbar ist, gehört automatisch in einen einfachen Unit-Test. Manche Dinge brauchen Integrationstests, andere eher End-to-End-Tests oder ganz andere Werkzeuge. Gerade deshalb lohnt es sich, sauber zu unterscheiden, was du eigentlich prüfen willst.

Wenn du mit JUnit arbeitest, dann starte nicht mit möglichst vielen Tests, sondern mit sinnvollen Tests. Prüfe kritische Logik, nimm Randfälle ernst und halte deine Tests lesbar. Dann sind sie keine lästige Pflicht, sondern ein Werkzeug, das dir im Alltag wirklich hilft.