TypeScript 测试数据构建：Builder、Fixture 与 Mock 类型约束的可维护写法

很多测试变得难维护，不是因为断言不会写，而是因为测试数据越来越乱。开始大家只是在测试里手写两个对象，后面对象字段一多、状态一复杂、上下游依赖一多，就会出现同样的坏味道：几十个测试各自复制一份数据，改一个字段要全仓搜，某些对象甚至组合出了业务里根本不可能出现的状态。

TypeScript 在测试数据治理里最大的价值，是把“可构造什么状态”这件事也做成显式规则。Builder、fixture 和 mock 并不是三种可互换工具，而是分别解决三种不同问题：场景默认值、可复现输入和依赖替身。把这三者混用，测试会越来越脆；把它们拆开，维护成本会明显下降。

先把三种东西分清：Builder、Fixture、Mock 各负责什么

工具	主要作用	最适合的场景
Builder	生成带默认值、可按需覆写的业务对象	领域对象、表单输入、状态数据
Fixture	固定一组可复现的完整样本	回归测试、快照测试、跨系统协议样本
Mock	替代外部依赖的行为	API、数据库、第三方服务、时间或随机数

最常见的问题，是把它们全都叫“测试数据”，然后在同一个测试里既复制对象，又手写假函数，再顺手塞一个不完整 fixture。这样做的后果通常不是“多写一点”，而是职责全乱了。

Builder 的价值，在于给场景一个稳定起点，而不是让你随便拼对象

一个健康的 Builder 通常有两个特征：

默认值代表一个真实且可用的业务状态。
覆写入口只允许改变合理字段，而不是把所有属性都开放成 Partial<any>。

type User = {
    id: string
    name: string
    role: 'admin' | 'editor' | 'viewer'
    active: boolean
}

function buildUser(overrides: Partial<User> = {}): User {
    return {
        id: 'user-001',
        name: 'Alice',
        role: 'viewer',
        active: true,
        ...overrides
    }
}

这个模式简单，但很有效：大部分测试只关心一两个字段时，不需要每次重新写完整对象。更重要的是，默认值形成了“基准状态”，团队不会再每个测试各自发明一套初始世界。

Partial 虽然方便，但它经常把“不可能状态”悄悄引进测试

很多项目会进一步把 Builder 做成 buildOrder(overrides: Partial<Order>)，然后觉得已经足够灵活。问题在于，Partial 本身只代表“字段可选”，并不代表“业务状态合法”。

举个例子：

订单 status 是 paid，但 paidAt 却是 null
表单 submitted 是 true，但 errors 里还留着必填缺失

这类数据在测试里很常见，因为手工拼对象时没人会顺手维护所有关联字段。更稳妥的做法是给关键状态提供场景化 Builder，而不是把一切交给通用覆写：

function buildPaidOrder(overrides: Partial<Order> = {}): Order {
    return {
        ...buildOrder(),
        status: 'paid',
        paidAt: '2026-06-08T10:00:00Z',
        ...overrides
    }
}