JUnit单元测试环境搭建全攻略：从版本选择到避坑排查

简介：这份实验报告文档面向正在学习软件测试与Java单元测试的学生及初学者，围绕Junit的安装配置与实例应用展开，帮助读者理解单元测试在实际编码中的作用与基本流程。文档以经典的“佣兵问题”为案例，完整呈现了枪机、枪托、枪管销售与佣金计算的业务逻辑，并给出对应的Java实现代码，便于读者对照理解被测程序的结构与边界条件。资源包共1个docx文件，大小约1.09MB，内容涵盖问题描述、代码实现、测试用例设计与测试结果展示，读者可从中学习如何运用边界值测试方法分析佣金的最大值、最小值与中点，并据此设计有效测试用例。文档还保留了运行输出与断言判断的细节，适合作为课堂实验报告参考或课后练习素材，帮助读者掌握Junit断言、测试类组织及测试结果验证的完整思路。目前已有4895人学习下载，可作为软件测试入门阶段的一份实践型参考资料。

1. 从一份跑不起来的实验报告说起：JUnit 单元测试环境到底怎么装

很多人第一次接触 JUnit 单元测试，是从一份实验报告开始的：代码看着没问题，测试类也照着写了，结果一运行就报红，要么是junit.framework.TestCase找不到，要么是@Test注解不生效，要么是 IDEA 里右键根本没有 “Run Test” 选项。这类问题十有八九不是测试逻辑写错，而是环境没搭对——JUnit 的版本、依赖的引入方式、测试类的目录位置，任何一处不对，整套单元测试就跑不通。这份实验报告围绕一个佣金计算程序展开，用边界值法设计了 27 条用例，覆盖最小值、边界点、越界输入等场景，正好是一套完整的 JUnit 落地练习素材。下面按“装什么版本、怎么配依赖、怎么写测试、坏了怎么救”的顺序，把这条环境从零走一遍，新手能照着复现，熟手能对照版本差异和参数取舍。

2. 环境准备与版本选择：JUnit 4 还是 JUnit 5，先定死再动手

2.1 先看清这份实验报告用的是哪套 JUnit

实验报告里的测试代码有两个非常明确的信号：一是import junit.framework.TestCase;，二是测试类public class SalaryTest extends TestCase。这两处说明它用的是 JUnit 3 风格的写法，而@Before、@After、@Test这些注解又是 JUnit 4 才引入的。也就是说，这份代码实际上是“JUnit 4 的注解 + JUnit 3 的 TestCase 继承”混着用，这种写法在 JUnit 4 下能跑，但属于过渡期写法，不是推荐姿势。

我一般会先把版本定死，再动手装。原因是 JUnit 4 和 JUnit 5 的包名、注解、运行器完全不同，混着装最容易出现“注解不生效”的玄学问题。对照这份报告，最省事的做法是直接用 JUnit 4.13.2，它同时兼容TestCase继承和@Test注解，报告里的代码几乎不用改就能跑。如果换成 JUnit 5，junit.framework.TestCase直接不存在，测试类得整个重写。

提示：实验报告类作业优先选 JUnit 4.13.2，别一上来就追新版本，否则报告里的extends TestCase和junit.framework导入全要重写，时间全耗在改代码上。

2.2 JDK 与构建工具的版本对齐

JUnit 4.13.2 要求 JDK 5 以上，实际用 JDK 8 或 JDK 11 都稳。报告里的Salary.java用了Scanner做控制台输入，测试时要把输入逻辑注释掉、直接传参，这一点后面写测试类时会处理。构建工具方面，IDEA 自带 Maven 和 Gradle 支持，但实验报告场景下很多人是纯 Java 项目，没有pom.xml，这时候就得手动加 jar 包。

我一般会分两条路走：有 Maven 就用依赖管理，没有就手动下载junit-4.13.2.jar和hamcrest-core-1.3.jar两个包。注意hamcrest-core是 JUnit 4 的断言依赖，只加 junit 包不加 hamcrest，运行时会报NoClassDefFoundError: org/hamcrest/SelfDescribing，这是新手最常翻的车之一。

# 手动方式：把两个 jar 放到项目 lib 目录 # junit-4.13.2.jar 提供测试框架本体 # hamcrest-core-1.3.jar 提供 assertThat 等匹配器依赖 mkdir -p lib # 下载后放入 lib，再在 IDEA 中 Add as Library

上面这段是目录准备，关键在“两个包都要”。很多人只下了 junit 一个包，编译能过，一运行就崩，报错信息还指向 hamcrest，容易误以为是 JUnit 装坏了。参数上，junit-4.13.2是主版本，hamcrest-core-1.3是配套版本，别去下 hamcrest 2.x，2.x 的包结构和 1.3 不同，JUnit 4 认的是 1.3 的org.hamcrest包路径。

2.3 IDEA 中 JUnit 插件的安装与模块配置

报告里提到“settings->Plugins 搜索安装”和“Project Structure 中添加模块 Junit”，这两步对应 IDEA 的插件和库配置。现代 IDEA 版本（2021 以后）其实已经内置 JUnit 支持，插件市场里搜 “JUnit” 主要是辅助生成测试类的插件，不是运行必需。真正要配的是 Project Structure 里的 Libraries。

操作顺序我一般这样走：File -> Project Structure -> Libraries -> + -> Java，选中 lib 目录下的两个 jar，应用到当前模块。配完后在项目外部库列表里能看到junit-4.13.2和hamcrest-core-1.3两项。如果只看到 junit 一项，说明 hamcrest 没加进去，后面断言方法会缺。

# Maven 方式则直接在 pom.xml 声明，省去手动加库 # scope 必须是 test，表示只在测试编译和运行期可见

<dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13.2</version> <scope>test</scope> </dependency>

这段pom.xml片段里，scope写test是关键参数：它让 JUnit 只参与测试阶段，不打进主程序产物。如果写成compile，打包时会把测试框架带进正式包，属于典型的配置污染。版本号4.13.2对应报告代码的兼容性，别随手改成4.12，4.12 对某些 JDK 11 环境有反射警告，虽然能跑但日志不干净。

3. 测试类落地：从 Salary.java 到 SalaryTest.java 的完整改造

3.1 被测类的目录结构与包名对齐

报告里Salary.java的包名是package main;，测试类SalaryTest.java也是package main;。这个细节很重要：JUnit 4 默认要求测试类和被测类在同一个包下，或者测试类能访问到被测类的可见性。Salary的构造方法和totalPrice()、commission()都是public，跨包也能访问，但为了省事，测试类放同包最稳。

目录结构我一般这样摆：

src/ ├── main/ │ └── java/ │ └── main/ │ └── Salary.java └── test/ └── java/ └── main/ └── SalaryTest.java

Maven 标准结构下，src/main/java放主代码，src/test/java放测试代码，两边包名都写main。这样mvn test能自动识别测试类。纯 IDEA 项目没有这层结构，就手动建test目录并 Mark as Test Sources Root，否则 IDEA 不会把里面的类当测试跑，右键菜单里没有 “Run”。

注意：测试类文件名必须以Test结尾（如SalaryTest），这是 Maven Surefire 插件的默认扫描规则。命名不对，mvn test会显示 0 个测试，让人误以为测试没写对。

3.2 把控制台输入改成参数化构造

报告里的Salary主方法用Scanner读三个数量，测试类里这段被注释掉了，改成直接new Salary(10, 20, 30)。这个改造是必须的：单元测试不能依赖控制台输入，否则跑测试时程序卡在in.nextInt()等人敲键盘，CI 环境直接挂死。

// SalaryTest.java 核心测试方法 @Test public void testTotalSalary() { int locks = 10; int stocks = 20; int barrels = 30; Salary salary = new Salary(locks, stocks, barrels); // 10*45 + 20*30 + 30*25 = 450 + 600 + 750 = 1800 // 佣金：1800 落在 (1000,1800] 区间，1000*0.1 + 800*0.15 = 100 + 120 = 220 Assert.assertTrue(salary.equals(1800, 220, salary)); }

这段代码对应报告里的测试用例，locks=10, stocks=20, barrels=30算出的销售额正好是 1800，佣金 220，属于边界点用例。salary.equals(1800, 220, salary)调用的是Salary类里自定义的equals方法，判断实际计算结果和预期值是否一致。参数含义：第一个1800是预期销售额，第二个220是预期佣金，第三个salary是被比较对象。

这里有个坑要说清楚：Salary类里重写的equals(double, double, Object)并不是Object.equals(Object)的标准重写，它是三参数的自定义方法，所以Assert.assertTrue里传的是它的返回值。如果误用Assert.assertEquals(1800, salary.totalPrice())，浮点数比较会有精度问题，得加 delta 参数，报告里用自定义 equals 反而绕开了这个坑。

3.3 边界值用例的批量落地写法

报告设计了 27 条用例，覆盖最小值、略大于最小值、中点、边界点、略高于边界点、越界输入等。逐条写@Test方法太啰嗦，我一般用参数化测试或者循环断言来压缩。JUnit 4 的参数化测试需要@RunWith(Parameterized.class)，写法偏重；实验报告场景下更实用的是在一个测试方法里循环多组数据。

@Test public void testBoundaryCases() { // 每组：枪机, 枪托, 枪管, 预期销售额, 预期佣金 int[][] cases = { {1, 1, 1, 100, 10}, // 最小值 {10, 10, 10, 1000, 100}, // 边界点 1000 {18, 18, 18, 1800, 220}, // 边界点 1800 {70, 80, 90, 7800, 1420}, // 最大值 }; for (int[] c : cases) { Salary s = new Salary(c[0], c[1], c[2]); Assert.assertEquals(c[3], s.totalPrice(), 0.001); Assert.assertEquals(c[4], s.commission(), 0.001); } }

这段循环断言里，assertEquals的第三个参数0.001是浮点比较的容差（delta），因为totalPrice和commission都是double，直接比会因精度误差失败。cases数组每行对应报告表格里的一条用例，注释标了场景。这种写法把 27 条用例压成几行数据，改起来也方便，加一行就多一条用例。

参数取舍上，delta取0.001是因为金额计算最多两位小数，千分之一容差足够覆盖浮点误差又不会放过真实错误。如果取0.1，可能把 0.05 的偏差也放过，测试就失去意义了。

4. 避坑与排查：JUnit 环境最常见的五类翻车现场

4.1 现象：右键没有 Run Test，测试类显示为普通 Java 类

原因通常是测试目录没标记为 Test Sources Root，或者测试类没有@Test注解、没有继承TestCase。IDEA 判断一个类是不是测试类，看的是注解或继承关系，两者都没有就当普通类处理。

解决：File -> Project Structure -> Modules，选中test目录点Mark as: Tests；同时确认测试方法上有@Test（org.junit.Test，不是org.junit.jupiter.api.Test）。如果两个注解混用，JUnit 4 运行器认不出 JUnit 5 的注解，方法会被跳过。

4.2 现象：运行报NoClassDefFoundError: org/hamcrest/SelfDescribing

原因只加了junit-4.13.2.jar，没加hamcrest-core-1.3.jar。JUnit 4 的断言体系依赖 hamcrest 的匹配器接口，缺了它类加载就失败。

解决：把hamcrest-core-1.3.jar补进 lib 并 Add as Library，或者 Maven 里确认 junit 依赖会自动传递 hamcrest-core。手动管理 jar 时最容易漏这一步，报错信息指向 hamcrest 而不是 junit，容易误判。

4.3 现象：@Test注解飘红，提示 “Cannot resolve symbol Test”

原因是导入写成了import org.junit.jupiter.api.Test;（JUnit 5）但项目里装的是 JUnit 4，或者反过来。两个版本的注解包路径完全不同，混用必然飘红。

解决：JUnit 4 用import org.junit.Test;，JUnit 5 用import org.junit.jupiter.api.Test;。对照报告代码，它用的是 JUnit 4 风格，导入统一改成org.junit.*系列。如果项目同时引了两个版本，清理掉不需要的那个依赖，别让两套注解共存。

4.4 现象：测试跑起来但断言全过，实际结果明显不对

原因是Salary类的totalPrice()和commission()有状态依赖：commission()内部读的是成员变量totalPrice，如果先调commission()再调totalPrice()，或者对象被复用，计算结果会串。报告里的equals方法同时调了totalPrice()和commission()，调用顺序影响结果。

解决：每个测试用例新建独立的Salary对象，别复用；测试方法里先调totalPrice()再调commission()，保证totalPrice成员变量已赋值。更彻底的做法是让commission()接收totalPrice作为参数，去掉成员变量依赖，但这属于改被测代码，实验报告场景下按原样测、按顺序调即可。

4.5 现象：越界输入用例期望“输入错误”，但测试没捕获到

报告里totalPrice()对越界输入打印“输入有错误！！！”并返回-1，但这是System.out.println加返回值，不是抛异常。测试类如果只断言返回值，得判断-1；如果期望异常，得用@Test(expected = ...)，但代码根本没抛异常，断言异常会失败。

解决：越界用例断言返回值等于-1，例如Assert.assertEquals(-1, s.totalPrice(), 0.001)。别写expected异常，代码里没有throw。这也是报告代码的一个设计瑕疵：错误处理靠打印和返回哨兵值，测试只能验返回值，验不了输出文本。

5. 装完怎么验证跑通：三条命令加一张对照表

环境装没装对，不看插件列表，看测试能不能真跑出结果。我一般按三步验证，每步都有明确的通过标准。

第一步，编译测试代码。命令行进项目根目录，Maven 项目执行mvn test-compile，纯 IDEA 项目用javac -cp lib/junit-4.13.2.jar:lib/hamcrest-core-1.3.jar -d out src/test/java/main/SalaryTest.java。通过标准是零报错，出现cannot find symbol就是依赖没加对。

第二步，跑单个测试类。Maven 用mvn test -Dtest=SalaryTest，纯命令行用java -cp out:lib/junit-4.13.2.jar:lib/hamcrest-core-1.3.jar org.junit.runner.JUnitCore main.SalaryTest。通过标准是输出OK (1 test)或OK (N tests)，出现FAILURES就得看具体断言。

第三步，对照报告用例表抽查。挑最小值(1,1,1)、边界点(10,10,10)、边界点(18,18,18)、最大值(70,80,90)四组，手动算一遍销售额和佣金，和测试输出比对。

这张表就是验证的标尺：测试输出和表里对不上，先查被测代码的费率公式，再查测试类的预期值传参。报告里 1800 这组佣金算的是1000*0.1 + 800*0.15 = 220，如果测试输出 220 就说明分段累计算法正确；输出 270 则是把 1800 整体乘了 0.15，属于典型的费率公式写错。

还有一个小技巧：在SalaryTest里加一个@Before方法打印当前用例参数，跑失败时日志里能直接看到是哪组数据翻的车，比对着 27 条用例表逐行排查快得多。@Before在每个测试方法前执行，适合做这种上下文输出。

@Before public void setUp() { System.out.println("=== 开始执行测试用例 ==="); }

这段@Before不参与断言，只做日志标记，参数为空。它的价值在失败现场：JUnit 输出里每个测试方法前都有这行标记，能快速定位是哪个方法出的问题。别在@Before里做重初始化，JUnit 4 每个测试方法都会新建测试类实例，@Before重复执行是正常的，但别在里面读文件、连数据库，拖慢整体测试。

从那以后我每次搭 JUnit 环境，都强制先跑一遍mvn test-compile再写测试逻辑，编译不过就别急着写断言，省得把依赖问题误判成代码问题。希望这套流程帮到你，照着走一遍，那份实验报告里的 27 条用例就能稳稳跑通。

本文还有配套的精品资源，点击获取