JUnit 4.12完整测试包获取、集成与单元测试实战指南

1. 项目概述：为什么你需要一份独立的JUnit 4.12测试包？

如果你正在学习Java，或者接手一个老项目，大概率会碰到一个让人头疼的报错：cannot resolve symbol ‘junit’。这个红红的波浪线，就像一道坎，拦住了你进行单元测试的路。很多新手会直接去网上搜索“JUnit 4.12下载”，结果要么是找到一堆过时的博客链接，要么是下载下来一堆看不懂的jar包，不知道哪个才是真正需要的。这个项目，就是来解决这个具体而微的痛点：为你提供一份清晰、完整、可直接使用的JUnit 4.12测试包，并手把手教你把它集成到你的项目中，让单元测试跑起来。

JUnit是Java领域单元测试的事实标准，而4.12版本是一个经典且广泛使用的稳定版本。尽管JUnit 5已经发布多年，但在维护历史项目、学习经典教材（很多仍以JUnit 4为例），或者在一些对依赖版本有严格限制的企业环境中，JUnit 4.12依然是绕不开的选择。所谓“完整测试包”，指的不仅仅是junit-4.12.jar这一个核心文件，还包括了它的“好搭档”——hamcrest-core-1.3.jar。从JUnit 4.11开始，JUnit就将匹配器（Matcher）功能分离到了Hamcrest库中，没有它，很多断言方法根本无法工作。因此，一份“完整”的包，必须包含这两个jar文件。

这份指南的价值在于，它不仅仅是一个下载链接的搬运工。我会带你理解每个文件的作用，解释集成时可能遇到的各种“坑”，并提供一个从零开始的单元测试实操示例。无论你是被cannot resolve symbol困扰的初学者，还是需要快速为老项目配置测试环境的老手，这篇指南都能让你避开我当年踩过的那些坑，直接上手。

2. 核心组件解析：JUnit 4.12包里到底有什么？

很多人以为下载JUnit就是下载一个jar包，结果导入项目后，测试类里一堆方法报错，根本没法用。这是因为没搞清楚JUnit 4.12的依赖构成。我们来彻底拆解一下。

2.1 核心依赖二重奏：JUnit与Hamcrest

一个能正常工作的JUnit 4.12环境，至少需要以下两个核心JAR文件：

1. junit-4.12.jar：这是JUnit框架本身。它包含了所有你熟悉的注解（@Test，@Before，@After）、断言方法（早期的assertEquals，assertTrue等）以及测试运行器。这个jar提供了单元测试的基本骨架和运行引擎。

2. hamcrest-core-1.3.jar：这是Hamcrest核心库。从JUnit 4.11开始，JUnit引入Hamcrest来提供更强大、更可读的断言（assertThat语法）。即使你不打算使用assertThat，JUnit内部的一些机制也依赖Hamcrest。缺少这个包，你的项目在编译时可能通过，但运行时一定会抛出NoClassDefFoundError，这是新手最常踩的坑之一。

注意：网上有些非常古老的教程或资源，可能提供的是junit-4.12.jar加上hamcrest-core-1.1.jar甚至更早的组合。虽然1.3版本是4.12的官方标配，但1.1在某些简单场景下也能工作。为了稳定和兼容性，我强烈建议使用hamcrest-core-1.3.jar。

2.2 可选但推荐的扩展包

除了上述两个必需项，在实际开发中，特别是集成测试或需要更多匹配器时，你可能会用到以下扩展：

• hamcrest-library-1.3.jar：它提供了大量预定义的、非常实用的匹配器（Matcher），比如用于集合判断的hasItem、hasSize，用于字符串的containsString、startsWith等。使用它可以让你的assertThat断言写得像自然语言一样流畅。它不是运行JUnit所必需的，但能极大提升测试代码的可读性和表达能力。
• junit-dep-4.12.jar：这是一个特殊的“依赖”包。在Maven或Gradle等构建工具中，当你声明依赖junit:junit:4.12时，实际上引入的是这个junit-dep包。它本身不包含Hamcrest的类，但会声明对hamcrest-core的依赖，让构建工具自动去下载。如果你手动管理jar包，直接使用前面提到的junit-4.12.jar和hamcrest-core-1.3.jar组合即可，不必纠结这个-dep版本。

实操心得：我习惯在项目的/lib（或/test-lib）目录下，永久保存junit-4.12.jar和hamcrest-core-1.3.jar这两个文件。这样即使在没有网络、或者构建工具出问题的极端情况下，我也能快速搭建起测试环境。对于hamcrest-library，我则视项目需求而定，通常只有在写了大量复杂断言时才会引入。

3. 获取与验证：如何安全地拿到正确的JAR包？

知道了需要什么，下一步就是去获取。这里我提供两种最可靠的方式，并教你如何验证你下载的包是正确、未被篡改的。

3.1 官方源下载（推荐用于学习理解）

虽然现在主流都用Maven中央仓库，但手动从官方源下载能让你更清楚文件的来源。JUnit和Hamcrest的官方发布托管在Sonatype的仓库和GitHub上。

1. 下载JUnit 4.12：

   • 访问Maven中央仓库的目录： https://repo1.maven.org/maven2/junit/junit/4.12/
   • 找到并点击下载junit-4.12.jar。
   • 同时，强烈建议下载junit-4.12.jar.asc（签名文件）和junit-4.12.pom（项目对象模型文件）。.asc文件可用于验证jar包的完整性（需要GPG工具，对新手可选）。.pom文件是XML格式，用文本编辑器打开，你可以看到它里面明确声明了对hamcrest-core的依赖，这印证了我们之前的说法。

2. 下载Hamcrest Core 1.3：

   • 访问： https://repo1.maven.org/maven2/org/hamcrest/hamcrest-core/1.3/
   • 找到并点击下载hamcrest-core-1.3.jar。

3.2 使用构建工具（推荐用于实际项目）

在实际的Java项目中，99%的情况你应该使用Maven或Gradle来管理依赖，包括测试依赖。这是最规范、最省事的方式。

Maven配置： 在你的pom.xml文件的<dependencies>部分添加如下依赖：

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

添加这个依赖后，Maven会自动从中央仓库下载junit-4.12.jar和它所依赖的hamcrest-core-1.3.jar。<scope>test</scope>意味着这个依赖只在编译和运行测试代码时有效，不会被打包到最终的生产环境（WAR/JAR）中，这是最佳实践。

Gradle配置： 在你的build.gradle文件的dependencies块中添加：

dependencies { testImplementation 'junit:junit:4.12' }

testImplementation的作用与Maven的testscope相同。

3.3 验证文件完整性

手动下载后，如何确认文件没问题？一个简单的方法是检查文件的基本信息和SHA1哈希。

1. 查看JAR清单：JAR文件本质上是一个ZIP包。你可以用解压软件（如7-Zip）打开它，查看META-INF/MANIFEST.MF文件。里面会包含版本、创建工具等信息。
2. 核对SHA1（推荐）：在Maven仓库的目录页，每个文件旁边都有一个“SHA1”链接，点开会显示一长串哈希值。在本地，你可以用命令行工具生成你下载文件的SHA1值进行比对。
   • Windows (PowerShell)：Get-FileHash -Algorithm SHA1 .\junit-4.12.jar
   • Linux/Mac：shasum junit-4.12.jar对比生成的哈希值与仓库页面显示的是否一致。这是确保文件在下载过程中未损坏或被篡改的有效手段。

踩过的坑：早期我曾从一些不知名的第三方网站下载“绿色版”或“破解版”的开发包，里面偶尔会被注入一些奇怪的类或修改清单，导致测试行为异常，排查起来极其困难。自此以后，我只信官方仓库或构建工具。

4. 集成到IDE：解决“Cannot resolve symbol”的实战

拿到了正确的jar包，接下来就是让它们在IDE里生效。这里以最流行的IntelliJ IDEA和Eclipse为例，演示如何手动添加库依赖。这个过程本质上就是告诉IDE：“嘿，我写测试代码要用到这些类，它们在这些jar文件里，请你编译和运行的时候能找到它们。”

4.1 IntelliJ IDEA 集成步骤

IDEA的项目结构（Project Structure）是管理依赖的核心。

1. 打开项目结构：File->Project Structure(快捷键Ctrl+Alt+Shift+S)。
2. 添加JAR依赖：
   • 在左侧选择Modules，然后在中间面板选择你的模块，切换到Dependencies标签页。
   • 点击右边的+号，选择JARs or directories...。
   • 在弹出的文件选择器中，同时选中你下载的junit-4.12.jar和hamcrest-core-1.3.jar（可以按住Ctrl多选），然后点击OK。
   • 关键一步：在添加后，确保这两个jar的Scope被设置为Test。这非常重要，它保证了这些依赖只在测试阶段被使用。
3. 验证：回到你的Java类中，尝试导入org.junit.Test。如果之前的红色错误提示消失，说明集成成功。你可以创建一个简单的测试类来验证。

4.2 Eclipse 集成步骤

Eclipse通过构建路径（Build Path）来管理依赖。

1. 右键项目：在项目资源管理器（Project Explorer）中，右键点击你的项目。
2. 配置构建路径：选择Build Path->Configure Build Path...。
3. 添加外部JAR：在弹出的窗口中选择Libraries标签页，点击Add External JARs...。
4. 选择JAR文件：导航到你存放jar包的目录，同样同时选中junit-4.12.jar和hamcrest-core-1.3.jar，点击打开。
5. 调整作用域（可选但推荐）：添加后，你可以展开添加的库，为每个jar包单独设置Classpath Entry的属性。更常见的做法是，将这些测试专用的jar包放在项目的lib或test-lib文件夹下，然后通过Add JARs...（而不是Add External JARs...）来添加，这样路径是相对的，项目迁移更方便。同样，理想情况下它们应该只用于测试，但在Eclipse手动管理时，严格区分Test作用域不如IDEA或构建工具方便，通常就放在默认的构建路径上。对于纯测试代码，这没有问题。
6. 验证：在Eclipse的Java编辑器中，编写导入org.junit.Test的语句，如果没有错误提示，即表示成功。

重要提示：无论使用哪种IDE，手动添加JAR包的方式在团队协作中都不是好主意，因为它无法保证其他成员环境的一致性。对于正式项目，务必使用Maven或Gradle进行依赖管理。上述手动步骤仅适用于快速实验、学习，或者维护无法使用构建工具的遗留项目。

5. 从零编写与运行你的第一个JUnit 4测试

环境搭好了，我们来真刀真枪地写一个测试。假设我们有一个简单的计算器类Calculator，它有一个add方法。我们将为它编写测试。

5.1 创建被测试类

首先，在src/main/java（Maven/Gradle项目）或你的源码目录下创建被测试的类。

// Calculator.java public class Calculator { public int add(int a, int b) { return a + b; } }

5.2 创建对应的测试类

按照惯例，测试类与被测试类同名，并以Test结尾。它应该放在src/test/java目录（如果使用标准项目结构）或单独的测试源码目录下。

// CalculatorTest.java import org.junit.Test; import static org.junit.Assert.*; public class CalculatorTest { @Test public void testAdd() { // 1. 准备 (Arrange) Calculator calculator = new Calculator(); int a = 5; int b = 3; int expected = 8; // 2. 执行 (Act) int actual = calculator.add(a, b); // 3. 断言 (Assert) assertEquals("加法计算错误", expected, actual); } }

代码解读：

• import org.junit.Test;：导入JUnit的@Test注解，用来标记一个方法是测试方法。
• import static org.junit.Assert.*;：静态导入Assert类中的所有静态断言方法。这样我们就可以直接写assertEquals而不是Assert.assertEquals，让代码更简洁。
• @Test：这个注解告诉JUnit，testAdd()方法是一个需要执行的测试用例。
• assertEquals([message], expected, actual)：这是最常用的断言方法。它比较期望值expected和实际值actual是否相等。可选的message参数会在测试失败时显示，对于定位问题非常有帮助。注意参数顺序：期望值在前，实际值在后，这个顺序一旦写反，失败信息会让人困惑。

5.3 运行测试并解读结果

在IDE中，你通常可以在测试类或测试方法旁边看到一个绿色的运行按钮（▶️）。点击它，选择“Run ‘CalculatorTest’”或“Run ‘testAdd()’”。

成功情况：你会看到IDE底部的一个运行工具窗口显示绿色对勾，并可能输出“Tests passed: 1”。这表示测试通过，add方法的行为符合预期。

失败情况：如果我们故意把断言改成assertEquals(9, actual)。再次运行测试，你会看到：

1. 运行窗口显示红色叉号或感叹号。
2. 会有明确的失败信息，例如：java.lang.AssertionError: 加法计算错误 expected:<9> but was:<8>。
3. 工具会指出失败发生在哪个文件的哪一行。

这个“红-绿”循环（先写一个失败测试，再修改代码使其通过）是测试驱动开发（TDD）的核心，也是验证代码功能的快速反馈机制。

实操心得：测试方法的命名，我强烈推荐使用should_When_或Given_When_Then的语义化格式，而不是简单的testMethodName。例如，should_ReturnSum_When_AddingTwoPositiveNumbers。这样读测试报告时，一眼就能看出这个用例在测什么场景，失败时也更容易理解上下文。虽然例子中用了testAdd，但在实际项目中请考虑更清晰的命名。

6. JUnit 4.12核心注解与生命周期详解

@Test只是JUnit注解家族的冰山一角。理解这些注解及其执行顺序（生命周期）是编写有效测试套件的基础。

6.1 核心测试注解

• @Test：标记测试方法。它还可以接受两个常用参数：

  • expected：期望测试方法抛出某种异常。例如@Test(expected = IllegalArgumentException.class)表示这个测试方法应该抛出IllegalArgumentException，如果不抛或者抛其他异常，测试失败。这在测试错误处理逻辑时非常有用。
  • timeout：设定测试方法的超时时间（毫秒）。例如@Test(timeout = 1000)表示如果测试方法执行超过1秒，则判定为失败。用于防止死循环或性能不达标的代码。

• @Before：在每个@Test方法之前执行。通常用于初始化测试所需的公共资源，比如创建被测对象实例、准备测试数据。如果一个测试类有多个@Test方法，那么每个@Test运行前，都会执行一次@Before标记的方法。

  public class CalculatorTest { Calculator calc; @Before public void setUp() { calc = new Calculator(); // 每个测试方法前都获得一个新的Calculator实例 System.out.println("setUp before each test"); } @Test public void test1() { /* 使用 calc */ } @Test public void test2() { /* 使用 calc */ } }

• @After：在每个@Test方法之后执行。通常用于清理资源，比如关闭数据库连接、删除临时文件、重置静态变量等。无论测试成功还是失败，@After方法都会执行，保证了清理工作的可靠性。

• @BeforeClass：在所有测试方法执行之前，仅执行一次。该方法必须是public static void。用于执行非常耗时的初始化操作，例如建立数据库连接池、加载大型配置文件。这些操作只需要做一次，且在所有测试间共享。

  @BeforeClass public static void initDatabase() { // 初始化数据库连接，整个测试类只执行一次 }

• @AfterClass：在所有测试方法执行之后，仅执行一次。该方法也必须是public static void。用于清理@BeforeClass中初始化的资源，例如关闭连接池、停止嵌入式服务器。

• @Ignore：标记一个测试类或测试方法被忽略，不执行。常用于临时跳过尚未完成或已知有问题的测试，同时保留测试代码。你可以提供一个字符串参数说明忽略的原因：@Ignore("功能尚未实现")。

6.2 测试生命周期与执行顺序

理解这些注解，就理解了JUnit测试的执行流：

@BeforeClass (一次) | v @Before (每次) -> @Test -> @After (每次) | | | (循环每个@Test) | v v @Before (每次) -> @Test -> @After (每次) | v @AfterClass (一次)

一个常见的陷阱：在@Before方法里初始化了一个可变的共享资源（比如一个List），然后在多个@Test方法中修改它。由于@Before在每个测试前运行，你可能会以为每个测试都是从干净状态开始，但如果你在@Before中初始化的是静态变量或类成员变量并在测试中修改其内容，那么测试之间就会相互影响，导致测试结果不稳定。正确的做法是：要么在@Before中创建新的实例，要么在@After中重置状态。

7. 断言（Assertions）的进阶使用：从assertEquals到assertThat

断言是测试的灵魂，它定义了什么是“正确”。JUnit 4提供了两套断言体系。

7.1 经典断言 (org.junit.Assert)

这套断言方法简单直接，适用于大多数场景。常用方法包括：

• assertEquals(expected, actual)/assertEquals(message, expected, actual)：判断相等。对于浮点数，请使用assertEquals(double expected, double actual, double delta)，其中delta是允许的误差范围，例如assertEquals(0.3, 0.1+0.2, 0.0000001)。
• assertTrue(condition)/assertFalse(condition)：判断条件真/假。
• assertNull(object)/assertNotNull(object)：判断对象是否为null。
• assertSame(expected, actual)：判断两个对象引用是否指向同一个实例（==）。
• assertNotSame(expected, actual)：判断两个对象引用是否指向不同实例。
• assertArrayEquals(expectedArray, actualArray)：判断数组内容是否相等。
• fail(message)：直接让测试失败。常用于标记不应该执行到的代码分支。

这些方法在失败时都会抛出AssertionError。

7.2 Hamcrest匹配器与assertThat（更强大、更可读）

这是JUnit 4.4之后引入的现代断言风格，语法为：assertThat(actual, matcher)。它的优势在于：

1. 可读性极佳：读起来像自然语言。
2. 组合性强：匹配器可以灵活组合。
3. 错误信息清晰：失败时给出的信息通常更详细。

要使用assertThat，你需要静态导入：import static org.hamcrest.CoreMatchers.*;或者更具体的匹配器。

基本使用示例：

import static org.hamcrest.CoreMatchers.*; import static org.junit.Assert.assertThat; @Test public void testUsingAssertThat() { int result = calculator.add(2, 2); // 判断相等 assertThat(result, is(4)); // 判断不相等 assertThat(result, is(not(5))); // 判断大于、小于 assertThat(result, greaterThan(3)); assertThat(result, lessThan(5)); String name = "JUnit"; // 判断字符串包含 assertThat(name, containsString("Uni")); // 判断以...开头 assertThat(name, startsWith("JU")); // 判断以...结尾 assertThat(name, endsWith("it")); List<String> list = Arrays.asList("apple", "banana"); // 判断集合包含元素 assertThat(list, hasItem("banana")); // 判断集合大小 assertThat(list, hasSize(2)); // 判断多个条件（且） assertThat(result, allOf(greaterThan(3), lessThan(5))); // 判断多个条件（或） assertThat(result, anyOf(is(3), is(4))); }

is和equalTo：is是一个装饰器，让表达式更可读，assertThat(x, is(equalTo(y)))等价于assertThat(x, equalTo(y))，也等价于经典的assertEquals(y, x)。我个人喜欢用is，因为它读起来更顺口。

引入hamcrest-library：上面示例中的hasItem，hasSize，startsWith等方法并不在hamcrest-core中，而是在hamcrest-library里。如果你需要使用这些丰富的匹配器，需要额外引入这个库。在Maven中添加依赖：

<dependency> <groupId>org.hamcrest</groupId> <artifactId>hamcrest-library</artifactId> <version>1.3</version> <scope>test</scope> </dependency>

选择建议：对于简单的相等、布尔判断，经典断言完全够用且简洁。对于涉及集合、字符串匹配、数值比较等复杂条件，assertThat的组合性和可读性优势巨大。在团队中，可以约定统一的断言风格。

8. 测试套件与参数化测试

当测试用例越来越多时，我们需要更好的组织方式。

8.1 测试套件 (@RunWith+@SuiteClasses)

测试套件允许你将多个测试类组合在一起运行。这在你需要按模块或功能分组运行测试时非常有用。

import org.junit.runner.RunWith; import org.junit.runners.Suite; @RunWith(Suite.class) @Suite.SuiteClasses({ CalculatorTest.class, AnotherServiceTest.class, DatabaseTest.class }) public class AllUnitTests { // 这个类本身是空的，只是一个套件的容器 }

运行AllUnitTests类，JUnit会依次运行@SuiteClasses中指定的所有测试类。这在用构建工具（如Maven的mvn test）执行所有测试时不是必须的，因为构建工具默认会跑所有*Test类。但在IDE中，手动运行一个套件比逐个选择多个测试类要方便得多。

8.2 参数化测试 (@RunWith(Parameterized.class))

当你想用多组不同的输入数据来测试同一个方法逻辑时，参数化测试能避免写大量重复的测试方法。

import org.junit.Test; import org.junit.runner.RunWith; import org.junit.runners.Parameterized; import org.junit.runners.Parameterized.Parameters; import java.util.Arrays; import java.util.Collection; import static org.junit.Assert.assertEquals; @RunWith(Parameterized.class) public class CalculatorParameterizedTest { private int inputA; private int inputB; private int expectedSum; private Calculator calculator = new Calculator(); // 构造函数，参数顺序和类型必须与 @Parameters 方法返回的集合元素顺序一致 public CalculatorParameterizedTest(int a, int b, int expected) { this.inputA = a; this.inputB = b; this.expectedSum = expected; } // 静态方法，返回一个集合，每个元素是一个Object数组，代表一组测试参数 @Parameters(name = "{index}: {0}+{1}={2}") // 可选，为测试用例生成易读的名称 public static Collection<Object[]> data() { return Arrays.asList(new Object[][] { { 1, 2, 3 }, { 0, 0, 0 }, { -1, 1, 0 }, { 99, 1, 100 } }); } @Test public void testAddWithParameters() { assertEquals(expectedSum, calculator.add(inputA, inputB)); } }

运行这个测试类，JUnit会为data()方法返回的每一组参数（共4组）都执行一次testAddWithParameters方法，相当于写了4个独立的测试方法。测试报告中的用例名会是“[0: 1+2=3]”， “[1: 0+0=0]”等，非常清晰。

注意事项：

• 测试类必须使用@RunWith(Parameterized.class)修饰。
• 必须有一个@Parameters修饰的静态方法，返回Collection<Object[]>。
• 必须有一个公共构造函数，其参数与@Parameters方法返回的集合中每个Object[]的元素一一对应。
• 参数化测试不支持@Before和@After注解（但支持@BeforeClass和@AfterClass），因为@Before/@After是在每个测试方法前后执行，而参数化测试只有一个测试方法（被多次调用）。如果需要在每次参数调用前后做事情，可以把逻辑直接写在测试方法里。

9. 常见问题排查与实战技巧

即使按照指南操作，你也可能会遇到一些奇怪的问题。这里汇总了一些典型场景和解决方案。

9.1 编译错误：“Cannot resolve symbol ‘junit’”

这是最经典的问题。

• 检查项1：依赖是否成功添加？在IDE中，打开项目结构/构建路径，确认junit-4.12.jar和hamcrest-core-1.3.jar确实在依赖列表中，并且路径正确。
• 检查项2：作用域（Scope）是否正确？如果是在非测试代码（如src/main/java）中导入了JUnit类，而JAR的作用域是Test，那么在这些地方就会找不到。确保测试代码位于正确的测试源码目录（如src/test/java）。
• 检查项3：IDE缓存问题？尝试执行IDE的“刷新项目”、“重新构建”或“清理并重建”操作。对于Maven项目，可以尝试mvn clean compile。
• 终极方案：如果手动管理JAR很混乱，强烈建议转换为Maven或Gradle项目，让构建工具管理依赖，一劳永逸。

9.2 运行时错误：“NoClassDefFoundError” 或 “NoSuchMethodError”

• NoClassDefFoundError：通常是缺少依赖的JAR。对于JUnit 4.12，99%的情况是缺少hamcrest-core-1.3.jar。请确保它和junit-4.12.jar在同一个类路径下。
• NoSuchMethodError：通常是版本冲突。例如，你的项目依赖了另一个库，它自身依赖了旧版本的JUnit（如4.10），而你的代码用了4.12的新方法。使用Maven的mvn dependency:tree命令查看依赖树，排除掉冲突的旧版本依赖。

9.3 测试运行器冲突 (@RunWith)

一个测试类只能有一个@RunWith注解。如果你同时想用参数化测试（Parameterized）又想用Spring的测试运行器（SpringJUnit4ClassRunner），就会冲突。解决方案是使用规则（Rules）或更高级的运行器封装。对于Spring，通常使用SpringRunner（JUnit 4的别名是SpringJUnit4ClassRunner），它本身不支持参数化。这时可以考虑将参数化部分抽离，或者使用Spring的@TestPropertySource等注解配合@Before方法来模拟参数化。

9.4 测试执行顺序

JUnit 4不保证测试方法的执行顺序。这是设计使然，目的是让每个测试都是独立的、不依赖于其他测试的执行。如果你的测试因为执行顺序不同而时好时坏，那说明测试之间存在状态共享或副作用，这是测试代码的坏味道（Bad Smell）。你需要重构测试，使用@Before为每个测试初始化独立的状态，并用@After清理。

9.5 性能测试与超时

对于耗时操作，使用@Test(timeout=毫秒数)来设置超时。但要注意，这是在单个测试方法层面的超时。如果你用@BeforeClass初始化了一个很慢的资源，这个超时设置是管不到的。对于性能基准测试，JUnit本身不是最佳工具，可以考虑JMH。

9.6 忽略测试 (@Ignore) 的合理使用

@Ignore应该被谨慎使用。它适合用于：

• 标记尚未实现的特性对应的测试（TODO测试）。
• 临时跳过因外部环境问题（如测试数据库宕机）而失败的测试。
• 跳过已知在特定平台或JDK版本下有问题的测试。不要用它来长期屏蔽一个总是失败的测试。一个总是失败的测试要么应该被修复，要么应该被删除。长期存在的@Ignore测试会成为代码库中的“僵尸”，浪费维护者的注意力。

我个人最深刻的教训：曾经在一个项目中，因为图省事，把hamcrest-core-1.3.jar和junit-4.12.jar放到了Web应用的WEB-INF/lib下（生产类路径）。结果应用发布后，在某些特定操作下触发了Hamcrest的类加载，导致了难以预料的类冲突。自那以后，我严格恪守“测试依赖作用域必须是Test”的原则，在Maven/Gradle中仔细检查<scope>test</scope>，手动管理时也绝不把测试库混入生产类路径。依赖隔离，是保持项目健康的基础。