当前位置：首页 > news >正文

完整教程：从测试坏味道到优雅实践：打造高质量单元测试

news 2026/5/11 21:39:14

从测试坏味道到优雅实践：打造高质量单元测试

在日常的单元测试开发中，我们常常会写出一些看似能跑，但维护性、可靠性都很差的测试代码，这些代码被称为“测试坏味道”。它们不仅会拖慢团队的开发效率，还会让测试逐渐失去应有的价值。今天，我们就来系统梳理这些常见的测试坏味道，并给出对应的优化方案，帮助你写出更健壮、更优雅的单元测试。

一、常见的测试坏味道盘点

1. 难懂的用例名称

测试方法的命名是测试代码的“第一注释”，一个模糊的命名会让后续维护者完全不知道这个测试的意图。

反例：

public void testJoin() {}
public void testTax() {}

正例（采用 should_xxx_when_xxx 风格，清晰表达预期行为）：

public void should_NOT_append_separator_for_array_with_only_one_element() {}
public void should_return_empty_string_when_join_empty_array() {}
public void should_calculate_10percent_tax_for_imported_luxury_goods() {}

2. 单个测试中包含过多场景

一个测试方法只应该验证一个核心场景。如果把多个场景塞进同一个测试里，一旦失败，你很难定位到底是哪部分逻辑出了问题。

反例：

@Test
public void testJoinAllScenarios() {
// 场景1：空数组
StringUtils.join(new String[]{}, ",");
// 场景2：单元素数组
StringUtils.join(new String[]{"a"}, ",");
// 场景3：含null元素的数组
StringUtils.join(new String[]{"a", null, "b"}, ",");
}

正例：

拆分成多个独立的测试方法，每个方法只验证一个场景：

@Test
public void should_return_empty_string_when_join_empty_array() {}
@Test
public void should_NOT_append_separator_for_array_with_only_one_element() {}
@Test
public void should_join_array_elements_which_contains_null() {}

3. 无法重复运行的测试

可重复运行是自动化测试的生命线。如果一个测试只能跑一次，第二次就报错，那它基本失去了自动化的意义。

反例：

@Test
public void should_return_user_count() {
// 问题：重复运行时，数据已存在会导致主键冲突
userRepository.save(new User("Jim"));
Long count = userRepository.count();
assertThat(count, is(1));
}

正例：

通过 @BeforeEach 和 @AfterEach 保证测试的独立性和可重复性：

@BeforeEach
void setUp() {
// 每次测试前清空数据
userRepository.deleteAll();
}
@Test
public void should_return_user_count() {
userRepository.save(new User("Jim"));
Long count = userRepository.count();
assertThat(count, is(1));
}

4. 测试依赖于特定的环境

如果你的测试必须依赖测试环境中的特定配置、外部服务或固定数据，那它很脆弱，在不同机器或环境上很容易失败。

优化思路：

使用 Mock 框架（如 Mockito）隔离外部依赖
采用内存数据库（如 H2）替代真实数据库
所有测试数据都在测试内部生成，不依赖外部静态数据

5. 永不失败的测试

一个永远不会失败的测试，比没有测试更糟糕。它会给你一种“功能是对的”的虚假安全感。

反例：

@Test
public void testTaxCalculation() {
// 永远为true，不会失败
Assert.assertTrue(true);
}

正例：

测试必须在行为符合预期时通过，不符合预期时失败：

@Test
public void should_calculate_50percent_tax_for_luxury_goods() {
int tax = taxCalculator.calcTax(false, Category.JEWELRY, 100.0);
// 明确验证预期结果
assertThat(tax, is(50));
}

6. 晦涩的断言

模糊的断言会让维护者很难理解测试的预期结果。

反例：

Assert.assertEquals(50, tax);

正例（使用 AssertJ 等提供更具描述性的断言）：

// 语义更清晰，失败时提示也更友好
assertThat(tax).isEqualTo(50);
assertThat(userList).hasSize(3).extracting("name").contains("Jim", "Tom");

二、高质量测试用例设计实践

1. 测试用例设计的核心思路

以 calcTax 函数为例，我们可以通过等价类划分来设计用例：

是否进口：2种情况（是/否）
商品类别：7种情况（粮食、药品、烟酒、咖啡、首饰等）
价格区间：3种情况（0、正数、边界值如1.99）

理论上，组合后的测试用例数为：2 × 7 × 3 = 42 个。这确保了我们覆盖了所有核心场景。

2. 三段式测试结构（Given-When-Then）

一个清晰的测试方法应该遵循 Given-When-Then 结构，让读者一眼就能看懂测试的逻辑：

Given：准备测试数据和环境
When：执行被测试的行为
Then：验证执行结果

示例：

@Test
public void should_calculate_10percent_tax_for_imported_goods() {
// Given
boolean isImport = true;
Category category = Category.FOOD;
double price = 100.0;
// When
int tax = taxCalculator.calcTax(isImport, category, price);
// Then
assertThat(tax).isEqualTo(10);
}

3. 断言工具选择：JUnit Assert vs AssertJ

特性	JUnit Assert	AssertJ
可读性	较低，需要记忆方法名	非常高，流式API，语义自然
失败提示	信息模糊	信息详细，直接说明预期与实际值
扩展性	较弱	支持自定义断言，扩展性强
推荐使用 AssertJ，它能让你的断言更具表达力，维护成本更低。