JUnit 5 und Mockito: Java-Tests schreiben

Kurz: JUnit 5 führt automatische Tests für Java aus, Mockito ersetzt Abhängigkeiten durch Attrappen (Mocks), damit einzelne Klassen isoliert und schnell geprüft werden können.

Genauer: Unit-Tests prüfen kleine Einheiten (Methoden/Klassen) automatisch. Sie fangen Fehler früh, erleichtern Refactoring und dokumentieren das gewünschte Verhalten. In Java ist JUnit der Standard.

Im Detail

Ein erster Test

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
 
class RabattTest {
    @Test
    void zehnProzentVonHundert() {
        assertEquals(90.0, Rabatt.anwenden(100.0, 10), 0.001);
    }
 
    @Test
    void negativerProzentwertWirftFehler() {
        assertThrows(IllegalArgumentException.class, () -> Rabatt.anwenden(100.0, -5));
    }
}

Ausführen: mvn test / ./gradlew test / IDE. Aufbau: Arrange (vorbereiten) – Act (ausführen) – Assert (prüfen). Annotationen: @Test, @BeforeEach, @AfterEach, @BeforeAll, @DisplayName, @Disabled, @Nested, @ParameterizedTest mit @ValueSource/@CsvSource. Assertions: assertEquals, assertTrue, assertNull, assertAll, assertThrows.

Mockito: Attrappen

Wenn eine Klasse eine Datenbank, Mail oder Web-API braucht, ersetzt man diese im Test:

import static org.mockito.Mockito.*;
 
@Test
void bestellungSendetMail() {
    MailService mail = mock(MailService.class);
    PreisService preise = mock(PreisService.class);
    when(preise.preis("A1")).thenReturn(20.0);
 
    var service = new BestellService(mail, preise);
    service.bestellen("A1", "kunde@example.org");
 
    verify(mail).senden(eq("kunde@example.org"), contains("20"));
    verifyNoMoreInteractions(mail);
}

when(...).thenReturn, verify(...), ArgumentCaptor, Spy, @Mock/@InjectMocks mit MockitoExtension. Dependency Injection (Konstruktor-Übergabe) macht Klassen testbar.

Gute Tests

• Klein, schnell, unabhängig, wiederholbar (F.I.R.S.T.), ein Verhalten pro Test, sprechende Namen.
• Randfälle: leer, null, Grenzwerte, Fehlerfälle.
• Nicht die Implementierung testen, sondern das Verhalten; nicht alles mocken (Wert-Objekte direkt verwenden).
• Zeit/Zufall injizieren (Clock).
• Testpyramide: viele Unit-, weniger Integrations-, wenige End-to-End-Tests; Testcontainers für echte DB-Tests.
• Testabdeckung (JaCoCo) als Hinweis, nicht Ziel; Mutation Testing (PIT).
• TDD: erst Test (rot), dann Code (grün), dann aufräumen.

Praxis und Prüfung

• CI führt Tests bei jedem Push aus; fehlschlagende Tests blockieren den Merge.
• Fehlersuche: Test reproduziert Bug vor dem Fix (Regressionstest).
• Spring Boot: @SpringBootTest, @WebMvcTest, MockMvc (siehe Spring).
• Typische Fehler: Tests hängen voneinander ab, echte Netzwerk-/Dateizugriffe, Thread.sleep, flaky Tests (Zeit/Reihenfolge).
• IHK-Projekt: Testkonzept/Testprotokoll (Testfälle, erwartetes/tatsächliches Ergebnis) nachvollziehbar dokumentieren.
• Verwandt: pytest (Python), Jest/Vitest (JS), Testarten im Überblick.

Siehe auch: Testarten im Überblick, Test-Driven Development, Maven und Gradle, Jest und Vitest