JUnit in Java

Du prüfst, dass eine kleine Methode den Wert zurückgibt, den du wolltest. In SumCheck.java behältst du ein package-privates Sum mit add, behältst die public Klasse SumCheck, markierst eine Methode mit @Test und rufst assertEquals(5, Sum.add(2, 3)); auf. Wenn 2 + 3 gleich 5 ist, besteht der Check. Eine zweite Demo prüft Sum.add(4, 5) gegen 9. Lass optionales JAR für die nächste Seite. Diese Lektion ist ein JUnit-Check mit assertEquals, kein Records-Zugriffsdruck und keine Streams-Pipeline.

Ein Check, der 5 will

Öffne SumCheck.java. Behalte den öffentlichen Klassennamen SumCheck. Lösche übriggebliebene Card-Records-Demos, übriggebliebene Pipe-Streams-Pipelines, übriggebliebene Cue-Lambda-Schritte und übriggebliebene Box-Scanner-Abfragen, wenn sie die JUnit-Geschichte überdecken. Die Lehrdatei ist eine Testklasse, kein main, das oak druckt.
Füge oben die Imports ein:
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
Behalte einen winzigen Helfer in derselben Datei:
class Sum {
static int add(int left, int right) {
return left + right;
}
}
In SumCheck schreibst du eine Testmethode:
@Test
void addsTwoAndThree() {
assertEquals(5, Sum.add(2, 3));
}
@Test markiert die Methode als Check, den der Runner ausführen soll. assertEquals nimmt zuerst den erwarteten und dann den tatsächlichen Wert. Hier ist erwartet 5 und tatsächlich Sum.add(2, 3). Sie stimmen überein, also besteht der Check.

Kompiliere und starte diese Datei mit einem JUnit-5-Runner auf deinem Classpath — eine IDE-Testschaltfläche oder ein Konsolen-Launcher-Jar, das die Klasse SumCheck wählt. Die Kursgewohnheit bleibt: „Quellcode des Tests kompilieren, dann die Checks ausführen.“ Du startest auf dieser Seite nicht java SumCheck wie ein normales main-Programm. Du druckst nicht t.name(). Du bittest den Runner, @Test-Methoden auszuführen.
Geh den Check einmal durch. Sum.add(2, 3) liefert 5. assertEquals(5, ...) vergleicht diese 5 mit der erwarteten 5. Sie stimmen. Der Check besteht. Eine Berichtzeile kann je nach Runner ein grünes Ergebnis oder eine kurze Erfolgszusammenfassung zeigen. Die wichtige Lehrbotschaft ist, dass erwartet und tatsächlich übereinstimmten.
Sag die Anfängerregel, während du auf die Methode schaust: @Test markiert den Check; assertEquals(expected, actual) vergleicht; benenne die Methode so, dass ein Mensch sie lesen kann. Erfinde auf dieser Seite keine JAR-Verpackungsdemos. JAR wartet auf die nächste optionale Lektion. Behandle keinen fehlschlagenden Check gegen 9 als dieses erste Demo — dieses erste Demo will 5.
Wenn du noch oak aus einer übriggebliebenen Card-Records-Datei siehst, wechsle zu SumCheck und behalte assertEquals(5, Sum.add(2, 3));. Findet der Runner keine Tests, prüfe, ob die Methode @Test hat und nicht so privat ist, dass dein Runner sie ablehnt.

Ein zweiter Check, der 9 will

Behalte dieselbe public Klasse SumCheck und denselben Sum-Helfer. Ändere den Testkörper für eine andere Summe:
@Test
void addsFourAndFive() {
assertEquals(9, Sum.add(4, 5));
}
4 + 5 ist 9. Erwartet ist 9. Tatsächlich ist Sum.add(4, 5). Sie stimmen, also besteht auch dieser Check. Halte auf dieser Seite einen klaren Check pro Lehrform, damit die erwartete Zahl leicht benennbar bleibt.

Geh den Check einmal durch. Sum.add(4, 5) liefert 9. assertEquals(9, ...) vergleicht erwartet und tatsächlich. Sie stimmen. Der Check besteht. Behalte die zwei Demos als zwei Lehrformen. Zuerst beweise einen Check, der 5 will. Dann einen, der 9 will. Beide Formen teilen die JUnit-Imports, den Sum-Helfer und @Test.
Verglich das erste Demo Sum.add(2, 3) mit 9, würde der Check scheitern, weil 5 nicht 9 ist. Dieses fehlschlagende Programm ist nicht die erste Lehrdatei. Die erste Lehrdatei will 5.

JUnit ist weder Records noch JAR

Records hielten kompakte Komponenten, die du mit Zugriffen drucktest. JUnit prüft ein Ergebnis gegen einen Wert, den du erwartet hast. JAR verpackt später auf einer optionalen Seite Klassendateien zum Versand. Mische diese drei Aufgaben heute nicht in einer Anfängerdatei.
5 hier ist der erwartete Wert in assertEquals. Es ist nicht t.n() aus einem Tag-Record und kein Stream-Map-Ergebnis. Wenn eine übriggebliebene Card-Datei noch oak druckt, lass das als Geschichte und behalte SumChecks Assertion-Zeile.
Ohne @Test führen viele Runner die Methode nicht als Check aus. Ohne assertEquals hast du in dieser Lehrform keinen Vergleich. Behalte beides. Halte JAR-Befehle bis zu jener Lektion von dieser Seite fern.

Runner- und Classpath-Gewohnheiten

JUnit-Typen leben in den Paketen org.junit.jupiter.api. Dein Editor oder Build-Tool muss diese Jars auf Compile- und Run-Classpath legen. Anfänger kleben oft die Testklasse korrekt ein und sehen trotzdem „package does not exist“, wenn die Jars fehlen — repariere den Classpath, nicht die @Test-Schreibweise.
Behalte Sum package-privat in derselben Datei, damit nur eine public Klasse SumCheck bleibt. Halte erwartete Werte als klare Literale in assertEquals. Halte Methodennamen lesbar. Halte gewöhnliches System.out.println aus den Lehr-Checks, außer du debuggst später selbst.
Schlägt die Kompilierung bei org.junit fehl, ist die Importzeile in Ordnung und die Bibliothek fehlt auf dem Classpath. Sagt der Runner null Tests gefunden, suche nach fehlendem @Test oder einem Klassennamen, den du nicht gewählt hast.

Ordner-Checks vor JAR

Liste den Ordner nach erfolgreichem Kompilieren mit verfügbaren JUnit-Jars. Du solltest SumCheck.class und meist Sum.class neben der Quelle sehen. Bearbeite die Quelle, speichere, kompiliere erneut, führe dann die Checks mit derselben Runner-Gewohnheit aus. Eine veraltete Klasse kann einen geänderten erwarteten Wert verstecken, wenn du nach einer Änderung das Kompilieren überspringst.
Beschwert sich javac über doppelte public Klassen, bleibt nur SumCheck public. Schlägt ein Check fehl, nachdem du assertEquals(9, Sum.add(2, 3)) eingegeben hast, ist diese Abweichung real — stelle das passende Paar für das Demo wieder her, das du behalten willst.
Klebe kein Card-record Tag in SumCheck. Ersetze assertEquals nicht durch Pipe-stream().map. Die optionale JUnit-Aufgabe ist ein markierter Check, der erwartet und tatsächlich vergleicht.

Vor optionalem JAR

Du kannst die public Klasse SumCheck behalten, den Helfer Sum.add behalten, JUnit-@Test und assertEquals importieren, Sum.add(2, 3) gegen 5 prüfen und dann Sum.add(4, 5) gegen 9. Kompiliere mit JUnit auf dem Classpath und führe die Checks mit einem JUnit-5-Runner aus. Die nächste optionale Seite ist JAR.
Behalte die SumCheck-Demos für ein klares Assertion-Paar. Halte Card-Records-Dateien von dieser Seite fern, wenn du JUnit übst. Halte Pipe-Streams-Dateien von dieser Seite fern, wenn du JUnit übst. Halte JAR-Arbeit bis zu jener Lektion von dieser Seite fern. Diese Gewohnheiten sind der Checkpoint, bevor du weitergehst. Will der erste Check 5 und besteht, oder will der zweite 9 und besteht, hat JUnit seine Aufgabe für diese Lektion erfüllt und du bist bereit für JAR, wenn du den optionalen Pfad weitergehst.
Ein letzter Durchgang im Ordner: eine public SumCheck, package-privates Sum, @Test vorhanden, assertEquals(expected, actual) ausgerichtet, JUnit-Imports vorhanden, kein Scanner-Warten, keine Stream-Pipeline nötig. Kompiliere und führe die Checks noch einmal auf dem Demo aus, das du offen hast. Stimmen erwartet und tatsächlich noch überein, ist die JUnit-Form solide und der Kurs kann auf der nächsten Seite zu optionalem JAR übergehen. Bevorzuge eine klare Assertion-Gewohnheit pro Lesedurchgang, damit jeder Durchgang dieselbe Landkarte lehrt.