Java 中的 JUnit

检查一个小方法是否返回你期望的值。在 SumCheck.java 中保留 package-private 的 Sum 与 add 方法，保留 public 类 SumCheck，用 @Test 标记一个方法，并调用 assertEquals(5, Sum.add(2, 3));。当 2 + 3 为 5 时，检查通过。第二次 demo 将 Sum.add(4, 5) 与 9 比对。可选 JAR 留到下一页。本课是用 assertEquals 做 JUnit 检查，不是 Records 的 accessor 打印，也不是 Streams 管道。

一次要 5 的检查

打开 SumCheck.java。public 类名保持 SumCheck。若 leftover 的 Card records demo、Pipe streams 管道、Cue lambda 遍历或 Box 的 Scanner 提示盖住了 JUnit 主线，请删掉它们。教学文件是测试类，不是打印 oak 的 main。
在文件顶部添加 import：
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
在同一文件里保留一个小助手：
class Sum {
static int add(int left, int right) {
return left + right;
}
}
在 SumCheck 内写一个测试方法：
@Test
void addsTwoAndThree() {
assertEquals(5, Sum.add(2, 3));
}
@Test 把方法标成 runner 应执行的检查。assertEquals 先接受期望值，再接受实际值。这里期望是 5，实际是 Sum.add(2, 3)。二者一致，检查通过。

在 classpath 上有 JUnit 5 runner 时编译并运行此文件——IDE 测试按钮，或选择类 SumCheck 的控制台 launcher jar。课程习惯仍是「先编译测试源码，再运行检查」。本页你不会像普通带 main 的程序那样启动 java SumCheck。你不会打印 t.name()。你要让 runner 执行带 @Test 的方法。
逐步走一遍检查。Sum.add(2, 3) 返回 5。assertEquals(5, ...) 把这个 5 与期望的 5 比较。一致。检查通过。报告可能显示绿色结果或简短成功摘要，取决于 runner。重要的教学事实是：期望与实际一致。
看着方法说出新手规则：@Test 标记检查；assertEquals(expected, actual) 做比较；给方法起人能读懂的名字。别在本页虚构 JAR 打包 demo。JAR 等下一堂可选课。别把对 9 失败的检查当成第一次 demo——第一次 demo 要 5。
若 leftover 的 Card records 文件仍让你看到 oak，请切换到 SumCheck 并保留 assertEquals(5, Sum.add(2, 3));。若 runner 找不到测试，确认方法有 @Test，且不是 runner 会拒绝的 private。

第二次要 9 的检查

保留同一 public 类 SumCheck 与同一 Sum 助手。改测试体以检查另一组求和：
@Test
void addsFourAndFive() {
assertEquals(9, Sum.add(4, 5));
}
4 + 5 为 9。期望是 9。实际是 Sum.add(4, 5)。一致，这次检查也通过。本页每种教学形态只保留一个清晰检查，便于说出期望数字。

逐步走一遍检查。Sum.add(4, 5) 返回 9。assertEquals(9, ...) 比较期望与实际。一致。检查通过。把两次 demo 当作两种教学形态。先证明要 5 的检查，再证明要 9 的检查。两种形态共享 JUnit import、Sum 助手与 @Test。
若第一次 demo 把 Sum.add(2, 3) 与 9 比较，检查会失败，因为 5 不是 9。那样失败的程序不是第一份教学文件。第一份教学文件要 5。

JUnit 不是 Records 也不是 JAR

Records 保存你用 accessor 打印的紧凑组件。JUnit 把结果与你期望的值比对。JAR 会在后面可选页打包 class 文件以便分发。今天别在一个入门文件里混这三件事。
此处的 5 是 assertEquals 里的期望值。不是 Tag record 的 t.n()，也不是 stream map 的结果。若 leftover 的 Card 文件仍打印 oak，把它当历史，保留 SumCheck 的 assertion 行。
没有 @Test，许多 runner 不会把方法当检查执行。没有 assertEquals，这种教学形态就没有比较。两者都要保留。在那堂课之前别把 JAR 命令放到本页。

Runner 与 classpath 习惯

JUnit 类型在 org.junit.jupiter.api 包中。编辑器或构建工具必须把相应 jar 放到编译与运行的 classpath。新手常把测试类贴对了，却在 jar 缺失时仍看到「package does not exist」——修 classpath，不是改 @Test 拼写。
在同一文件里让 Sum 保持 package-private，这样唯一 public 类仍是 SumCheck。在 assertEquals 里用清晰的字面量作期望值。方法名保持可读。除非你自己事后调试，别把普通 System.out.println 放进教学检查。
若编译在 org.junit 上失败，import 行没问题，是库不在 classpath。若 runner 说找到零个测试，查缺失的 @Test 或未选中的类名。

JAR 前的文件夹检查

在 JUnit jar 可用且编译成功后列出文件夹。应看到 SumCheck.class，通常旁边还有 Sum.class。编辑源码、保存、再编译，然后用同一 runner 习惯运行检查。若编辑后跳过编译，陈旧的 class 可能遮住改过的期望值。
若 javac 抱怨重复的 public 类，只保留 SumCheck 为 public。若在输入 assertEquals(9, Sum.add(2, 3)) 后检查失败，不匹配是真的——为你想保留的 demo 恢复匹配的配对。
别把 Card 的 record Tag 贴进 SumCheck。别把 Pipe 的 stream().map 当 assertEquals 的替代。可选的 JUnit 任务是带标记的比较期望与实际的检查。

可选 JAR 之前

你可以保留 public 类 SumCheck、助手 Sum.add，import JUnit 的 @Test 与 assertEquals，把 Sum.add(2, 3) 对 5 检查，再把 Sum.add(4, 5) 对 9 检查。在 classpath 上有 JUnit 时编译，用 JUnit 5 runner 运行检查。下一可选页是 JAR。
为清晰的 assertion 配对保留 SumCheck demo。练 JUnit 时别把 Card records 文件留在本页。练 JUnit 时别把 Pipe streams 文件留在本页。在那堂课之前别把 JAR 工作放在本页。这些习惯是继续前的检查点。第一次检查要 5 且通过，或第二次要 9 且通过，JUnit 在本课就完成了任务；若你走可选路径，已准备好 JAR。
最后再过一遍文件夹：一个 public SumCheck、package-private Sum、@Test 在位、assertEquals(expected, actual) 对齐、JUnit import 在位、无 Scanner 等待、不要求 stream 管道。在你打开的 demo 上再编译运行一次检查。若期望与实际仍一致，JUnit 形态稳固，课程可进入下一页的可选 JAR。每次阅读只保留一种清晰的 assertion 习惯，让每一遍都教同一张图。