Java JUnit

Check that a small method returns the value you wanted. In SumCheck.java, keep a package-private Sum with add, keep the public class SumCheck, mark a method with @Test, and call assertEquals(5, Sum.add(2, 3));. When 2 + 3 is 5, the check passes. A second demo checks Sum.add(4, 5) against 9. Leave optional JAR for the next page. This lesson is a JUnit check with assertEquals, not a Records accessor print and not a Streams pipeline.

One check that wants 5

Open SumCheck.java. Keep the public class name SumCheck. Delete leftover Card records demos, leftover Pipe streams pipelines, leftover Cue lambda walks, and leftover Box Scanner prompts if they bury the JUnit story. The teaching file is a test class, not a main print of oak.
Add the imports at the top:
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
Keep a tiny helper in the same file:
class Sum {
static int add(int left, int right) {
return left + right;
}
}
Inside SumCheck, write one test method:
@Test
void addsTwoAndThree() {
assertEquals(5, Sum.add(2, 3));
}
@Test marks the method as a check the runner should run. assertEquals takes the expected value first and the actual value second. Here expected is 5 and actual is Sum.add(2, 3). They match, so the check passes.

Compile and run this file with a JUnit 5 runner on your classpath — an IDE test button, or a console launcher jar that selects class SumCheck. The course habit is still “compile the test source, then run the checks.” You are not launching java SumCheck as an ordinary main program on this page. You are not printing t.name(). You are asking the runner to execute @Test methods.
Walk the check once. Sum.add(2, 3) returns 5. assertEquals(5, ...) compares that 5 to the expected 5. They match. The check passes. A report line may show a green result or a short success summary depending on the runner. The important teaching fact is that expected and actual agreed.
Say the beginner rule while you look at the method: @Test marks the check; assertEquals(expected, actual) compares; name the method so a human can read it. Do not invent JAR packaging demos on this page. JAR waits for the next optional lesson. Do not treat a failing check against 9 as this first demo — this first demo wants 5.
If you still see oak from a leftover Card records file, switch to SumCheck and keep assertEquals(5, Sum.add(2, 3));. If the runner finds no tests, confirm the method has @Test and is not private in a way your runner rejects.

A second check that wants 9

Keep the same public class SumCheck and the same Sum helper. Change the test body to check another sum:
@Test
void addsFourAndFive() {
assertEquals(9, Sum.add(4, 5));
}
4 + 5 is 9. Expected is 9. Actual is Sum.add(4, 5). They match, so this check passes too. Keep one clear check per teaching shape on this page so the expected number stays easy to name.

Walk the check once. Sum.add(4, 5) returns 9. assertEquals(9, ...) compares expected and actual. They match. The check passes. Keep the two demos as two teaching shapes. First prove a check that wants 5. Then prove a check that wants 9. Both shapes share the JUnit imports, the Sum helper, and @Test.
If the first demo compared Sum.add(2, 3) with 9, the check would fail because 5 is not 9. That failing program is not the first teaching file. The first teaching file wants 5.

JUnit is not Records and not JAR

Records held compact components you printed with accessors. JUnit checks a result against a value you expected. JAR will package class files for shipping on a later optional page. Do not mix those three jobs in one beginner file today.
5 here is the expected value in assertEquals. It is not t.n() from a Tag record and not a stream map result. When a leftover Card file still prints oak, leave that as history and keep SumCheck's assertion line.
Without @Test, many runners will not execute the method as a check. Without assertEquals, you have no comparison in this teaching shape. Keep both. Keep JAR commands off this page until that lesson.

Runner and classpath habits

JUnit types live in the org.junit.jupiter.api packages. Your editor or build tool must put those jars on the compile and run classpath. Beginners often paste the test class correctly and still see “package does not exist” when the jars are missing — fix the classpath, not the @Test spelling.
Keep Sum package-private in the same file so one public class remains SumCheck. Keep expected values as clear literals in assertEquals. Keep method names readable. Keep ordinary System.out.println out of the teaching checks unless you are debugging on your own later.
If compile fails on org.junit, the import line is fine and the library is missing from the classpath. If the runner says zero tests found, look for a missing @Test or a class name you did not select.

Folder checks before JAR

List the folder after a successful compile with the JUnit jars available. You should see SumCheck.class and usually Sum.class beside the source. Edit the source, save, compile again, then run the checks with the same runner habit. A stale class can hide a changed expected value if you skip compile after an edit.
If javac complains about duplicate public classes, keep only SumCheck public. If a check fails after you typed assertEquals(9, Sum.add(2, 3)), that mismatch is real — restore the matching pair for the demo you mean to keep.
Do not paste Card record Tag into SumCheck. Do not paste Pipe stream().map as a replacement for assertEquals. The optional JUnit job is a marked check that compares expected and actual.

Before optional JAR

You can keep public class SumCheck, keep helper Sum.add, import JUnit @Test and assertEquals, check Sum.add(2, 3) against 5, then check Sum.add(4, 5) against 9. Compile with JUnit on the classpath and run the checks with a JUnit 5 runner. The next optional page is JAR.
Keep the SumCheck demos for a clear assertion pair. Keep Card records files off this page when you practice JUnit. Keep Pipe streams files off this page when you practice JUnit. Keep JAR work off this page until that lesson. Those habits are the checkpoint before you move on. When the first check wants 5 and passes, or the second check wants 9 and passes, JUnit did its job for this lesson and you are ready for JAR if you continue the optional path.
One last pass through the folder: one public SumCheck, package-private Sum, @Test present, assertEquals(expected, actual) aligned, JUnit imports present, no Scanner wait, no stream pipeline required. Compile and run the checks once more on the demo you keep open. If expected and actual still match, the JUnit shape is solid and the course can move to optional JAR on the next page. Prefer one clear assertion habit per read so each pass teaches the same map.