3. 单元测试框架：JUnit / PyTest / NUnit 核心概念与对比

做单元测试，框架就是你的工具箱。JUnit、PyTest、NUnit —— 这三个名字几乎覆盖了 Java、Python、C# 三大阵营。它们背后思想其实差不多，但用起来细节差异不小。我带过几个跨语言团队，每次新人切换语言时总会在断言写法、参数化测试上栽跟头。今天就好好捋一捋。

3.1 它们到底解决了什么问题？

说白了，单元测试框架的核心只有三件事：
① 自动发现测试 —— 不用你手动一个个调用。
② 断言机制 —— 判断期望值和实际值是否一致。
③ 生命周期管理 —— 每个测试前后该做啥准备和清理。

三个框架都围绕这三点展开，只是语法和习惯不同。你想想看，Java 社区偏好注解，Python 喜欢约定优于配置，C# 则夹在中间，既有特性也有约定。

核心共识：测试函数独立、可重复、不依赖外部状态。不管用哪个框架，这条红线不能碰。

3.2 测试发现机制

框架怎么找到你的测试？这是第一个坑。

  • JUnit (Java)：通过反射扫描类和方法，要求方法加上 @Test 注解。类名不要求特定后缀，但习惯上叫 XxxTest。
  • PyTest (Python)：默认递归扫描文件名 test_*.py 或 *_test.py，然后找里面的 test_* 函数。不需要任何装饰器（但 @pytest.mark 可以附加标签）。
  • NUnit (C#)：类似 JUnit，使用 [Test] 特性标记方法。类也需标记 [TestFixture]，不过 NUnit 3+ 可以省略这个特性。
我个人习惯在 PyTest 项目里统一用 test_xxx.py 命名，避免 IDE 和 CI 工具配置混乱。Java 项目则坚持 类名Test 格式，Maven Surefire 插件默认就能识别。

3.3 断言写法对比

断言是测试的灵魂。三个框架的断言 API 各有风格：

框架断言示例特点
JUnit 5
assertEquals(expected, actual);
assertTrue(condition);
assertThrows(Exception.class, () -> obj.method());
静态方法，参数顺序是“期望值在前，实际值在后”。我一度记反过，报错信息会误导。
PyTest
assert result == expected
with pytest.raises(ValueError): func()
使用 Python 原生 assert，PyTest 通过重写 AST 输出详细的比较信息。非常优雅。
NUnit
Assert.That(actual, Is.EqualTo(expected));
Assert.Throws<Exception>(() => obj.Method());
约束模型，可读性强。缺点是需要记忆 Is.、Has. 等约束类。
我曾遇到过一个隐蔽的 bug：JUnit 里 assertEquals 对基本类型和封装类型的自动拆箱出过问题。比如 Integer.valueOf(200) 用 == 比较会失败，但 assertEquals 内部用的是 equals()，所以没事。可如果你用 assertTrue(a == b)，包装类就中招了。

3.4 参数化测试

测同一个逻辑需要多组数据时，参数化测试能省不少代码。三个框架都支持，但写法完全不同：

// JUnit 5 @ParameterizedTest
@ParameterizedTest
@ValueSource(strings = {"racecar", "radar", "level"})
void palindromes(String candidate) {
    assertTrue(isPalindrome(candidate));
}

# PyTest @pytest.mark.parametrize
@pytest.mark.parametrize("input,expected", [
    ("1+2", 3),
    ("3*4", 12)
])
def test_eval(input, expected):
    assert eval(input) == expected

// NUnit [TestCase]
[TestCase(1, 2, 3)]
[TestCase(2, 3, 5)]
public void Add_ReturnsSum(int a, int b, int sum) {
    Assert.That(a + b, Is.EqualTo(sum));
}

PyTest 的 parametrize 最灵活，甚至可以组合多个装饰器做笛卡尔积。JUnit 的 @CsvSource 也不错，但类型转换有时会报错。NUnit 的 [TestCase] 最直观，但参数多了文本就很长。

3.5 生命周期钩子

每个测试前后需要初始化或清理资源，比如打开数据库连接、创建临时文件。三个框架都定义了类似的钩子：

阶段JUnit 5PyTestNUnit
所有测试前执行一次@BeforeAllsetup_module / conftest.py scope="session"[OneTimeSetUp]
每个测试前执行@BeforeEachsetup_function / 夹具 yield[SetUp]
每个测试后执行@AfterEachteardown_function[TearDown]
所有测试后执行一次@AfterAllteardown_module[OneTimeTearDown]

PyTest 的 fixture 机制更强大，可以用 @pytest.fixture 定义返回对象，直接注入到测试函数参数里，自动处理作用域和清理。我建议用 yield 代替 return，这样清理代码自然写在 yield 后面，不容易漏掉。

3.6 知识结构图

下面这张图把三个框架的核心要素串起来了，方便你对照复习：

单元测试框架核心对比 JUnit (Java) PyTest (Python) NUnit (C#) @Test 注解 + 反射 test_ 前缀约定扫描 [Test] 特性 + 反射 assertEquals / assertThrows 原生 assert + pytest.raises Assert.That 约束模型 @ParameterizedTest @pytest.mark.parametrize [TestCase] 特性 @BeforeEach / @AfterEach fixture + yield 清理 [SetUp] / [TearDown] 注意：三条纵向箭头表示每个框架内发现→断言→参数化→生命周期的演进关系，横向对比三个框架的差异

3.7 选型建议

没有最好的框架，只有最适合你项目的。总结几条原则：

  • Java 项目：团队如果熟悉注解风格，无脑选 JUnit 5。加上 AssertJ 或 Hamcrest 做断言，可读性很高。别碰 TestNG 了，除非你有并发测试的硬需求。
  • Python 项目：PyTest 是事实标准，unittest 可以扔进垃圾桶。PyTest 的夹具、参数化、插件体系（比如 pytest-selenium）太香了。
  • C# 项目：.NET 社区现在分裂成 xUnit、NUnit、MSTest 三派。我个人推荐 NUnit，因为它的 Assert.That 约束模型出错信息非常清晰，而且社区成熟。xUnit 也不错，但它的 IDisposable 生命周期管理方式需要点时间适应。
如果你正好在做一个多语言的产品，比如微服务后端是 Java + Python，可以考虑统一测试输出的数据格式（比如 JSON 报告），这样 CI 流水线里收集报告的工具不用写两套。我之前的项目就把 JUnit 的 XML 报告和 PyTest 的 JUnitXML 报告接到同一个 Jenkins 插件上，省了不少事。

最后说个小坑：不要滥用参数化测试。我见过同事一个测试方法挂了 20 组参数，结果某个参数失败后，后面全被标记为 skipped（JUnit 5 默认行为），导致漏报。PyTest 默认全部跑完，但输出又特别长。建议每组参数保持业务独立，数据量超过 5 组就考虑拆分到多个测试类或用 CSV 文件载入。

嗯，这一章就聊到这儿。三种框架的核心概念你都掌握了，下一轮我们可以深入到每个框架的高级特性，比如并行执行、测试排序、条件测试这些实战技巧。

← 上一章 📖 返回目录 下一章 →