💡 1. Moderne Testsuites mit JUnit 5
JUnit 5 trennt API, Engine und Runner sauber. Tests validieren Annahmen mit sprechenden Assertions:
import org.junit.jupiter.api.*;
import static org.junit.jupiter.api.Assertions.*;
class RechnerTest {
private Rechner rechner;
@BeforeEach
void setUp() {
rechner = new Rechner();
}
@Test
@DisplayName("Division durch Null wirft IllegalArgumentException")
void testDivisionDurchNull() {
var ex = assertThrows(IllegalArgumentException.class, () -> {
rechner.dividiere(10, 0);
});
assertEquals("Teiler darf nicht 0 sein", ex.getMessage());
}
}
Ein Unit-Test ist wie die Qualitätskontrolle am Ende der Fertigungslinie. Jedes Bauteil wird einzeln auf Belastung geprüft, bevor es ins Gesamtprodukt eingebaut wird.
⚡ 2. Quick-Cheat-Sheet
| Annotation | Bedeutung | Zeitpunkt |
|---|---|---|
@Test | Markiert Methode als Testfall | Wird vom Test-Runner ausgeführt |
@BeforeEach | Setup-Methode | Läuft frisch vor JEDEM Testfall |
@AfterEach | Cleanup-Methode | Läuft nach jedem Testfall |
@ParameterizedTest | Datengesteuerter Test | Läuft mehrfach mit Testwerten (z.B. `@ValueSource`) |
⚠️ 3. Häufige Stolperfallen (Gotchas & Anti-Patterns)
Importiert man versehentlich das alte org.junit.Test (JUnit 4) statt org.junit.jupiter.api.Test (JUnit 5), ignoriert der moderne Runner den Test!
In JUnit 5 gilt: assertEquals(expected, actual). Vertauscht man sie, sind Fehlermeldungen bei Fehlschlägen irreführend.
🧠 4. Diagnostischer Selbst-Check
Überprüfe dein Verständnis von Sprach-Features, Speicherverwaltung und Enterprise-Architektur, bevor du den Code in der Web-IDE schreibst.