测试夹具这个中文词带着工业感，让第一次听到它的开发者往往去搜索"是不是翻译错了"。词源确实如此：fixture 来自机械加工，后来进入电子测试领域，再由 Kent Beck 引入软件测试框架里。这个词在软件工程里覆盖的范围，也远比"单元测试"要宽。

从车间到代码

fixture 这个词在机械加工里有精确含义：在 CNC 车床或焊接台上，fixture 是一种工装，把工件固定在已知位置，让每次加工操作都从相同的起点开始。与 jig（引导刀具路径的夹具）不同，fixture 的职责只有一件事——把工件钳牢，消除定位误差。

词源上，fixture 来自拉丁语 figere（刺入、固定），经 fixura（固定物）演变为英语词汇，约在 16 世纪末进入法律语言，最初指"永久附着于不动产的动产"——嵌入墙体的管道、固定在地板上的书架，那些不能随意拆走的东西。

电子测试领域用法相似：一块 PCB 插入测试夹具后被固定在已知电气状态，探针才能重复施加相同的激励、在相同节点读取信号，排除接触不稳定的干扰。

三种用法的共同语义：将某个对象固定在确定的、可重复的起始状态，以便后续操作只需关注自身变量，而非起点的不确定性。

Kent Beck 的命名

1994 年，Kent Beck 为 Smalltalk 写了测试框架 SUnit，并发表论文《Simple Smalltalk Testing With Patterns》。论文中用 fixture 描述测试运行所需的那组对象：setUp 将它们建立到已知状态，tearDown 负责清理，每个测试方法运行时都拿到一份全新的、确定的环境。

Beck 后来与 Erich Gamma 将 SUnit 移植为 JUnit（约 1997 年），JUnit 的文档给出了沿用至今的定义：

A test fixture is a fixed state of a set of objects used as a baseline for running tests. The purpose of a test fixture is to ensure that there is a well-known and fixed environment in which tests are run so that results are repeatable.

"fixed state of a set of objects"是对机械/电子夹具语义的直接移植：不是固定工件，而是固定测试对象的初始状态。这个命名不是比喻，是刻意的借词——Beck 在谈到 SUnit 的设计时明确提到，他从电子测试夹具里借用了这个概念。

JUnit 与 pytest 的两种实现哲学

JUnit 的 fixture 是生命周期式的：测试类的实例变量构成 fixture，setUp/tearDown（JUnit 4+ 对应 @Before/@After）负责建立和销毁，每个测试方法自动继承同一套初始化逻辑，无需显式声明。

pytest 在 2012 年（2.4 版本）将早期的 funcarg 机制正式改名为 fixture，引入了依赖注入模型：fixture 由 @pytest.fixture 声明，测试函数通过参数名请求所需的 fixture，框架负责解析和注入。

1
2
3
4
5
6
7
8
9
10
@pytest.fixture
def db_session():
    session = create_session()
    yield session
    session.rollback()

def test_create_user(db_session):
    user = User(name="alice")
    db_session.add(user)
    assert db_session.query(User).count() == 1

区别在于：JUnit 的每个测试类只有一套 fixture，由继承关系决定；pytest 的每个测试函数可以声明任意组合的 fixture，由参数名决定。前者更像类的成员变量，后者更像 IoC 容器里的 Bean。

pytest fixture 还引入了 scope 参数：function（默认，每测试独立）、module、session（整个测试会话共享），让昂贵资源（数据库连接、Docker 容器）能在合适的粒度上复用，而不必每个测试都从头重建。

fixture 走出测试

fixture 的核心语义超出了单元测试的边界——为某个操作提供固定的、已知的基础环境。

Django 用 manage.py dumpdata 导出数据库快照为 JSON/YAML，用 loaddata 导入，文件放在 <app>/fixtures/ 目录。这些文件可用于测试数据库初始化，也可用于演示环境和新实例的种子数据，与单元测试的对象图没有直接关系，但逻辑相同：操作开始前，将外部状态置于已知点。Rails 的 test/fixtures/ 类似，用 YAML 描述测试数据库的初始行记录，测试套件启动时自动加载。

Cypress 用 cy.fixture('data.json') 加载 cypress/fixtures/ 下的静态文件，通常配合 cy.intercept() 模拟 HTTP 响应——用固定文件替代真实网络调用，消除外部变量。

GitHub Actions 的 services: 字段允许在 Job 前启动 PostgreSQL、Redis 等服务容器，为测试 Job 提供固定的外部依赖环境。Zephyr OS 的嵌入式测试框架明确用 fixture 一词描述测试场景所需的硬件状态。

JMH（Java Microbenchmark Harness）用 @State 声明持有基准状态的类，@Setup(Level.Trial) 在每轮压测前初始化，与 JUnit 的 setUp 机制完全类似，目的也相同：为每次测量提供一致的起点，排除环境噪声。

这些用场横跨单元测试、E2E 测试、数据库管理、CI/CD 和性能测试，共同点是：在某个操作开始之前，将特定的外部状态（对象图、数据库内容、服务依赖、硬件配置）固定到已知位置。测试是其中最经典的场景，但不是唯一的。

中文翻译的困境

"夹具"是直译，在中文测试社区里使用频率最高，对应机械加工中的同一术语，准确但有工业感，很难让第一次读到它的开发者联想到对象初始化。

"固件"是常见的错误翻译——那是 firmware 的专属中译，指烧录在芯片里的嵌入式软件，和 fixture 毫无关系。把 pytest fixture 说成"固件"是概念混淆。

"测试桩"是另一个不该混用的词，那是 stub 的中译，指替代真实依赖的空壳实现，与 fixture 描述的初始化机制完全不同。

"前置条件"解释了 fixture 的作用，但丢掉了"固定状态"和"可重复性"的含义，更像描述性解释而非术语翻译。

在正式技术文档里，"测试夹具"是最不易误解的选择，与词源对应，又不与其他现有术语冲突。日常工程交流中，直接用 fixture 或框架全名（pytest fixture、JUnit fixture）反而更清晰，因为不同框架的 fixture 语义已经存在明显差异——同样叫 fixture，pytest 的实现哲学和 JUnit 的几乎是两套不同的系统设计。