用测试数据工厂把散落在用例里的硬编码数据收口：从 1200 处魔法值到单一数据源

一、现象与背景：改一个字段，要翻 47 个文件

先给数字。我接手一条 B 端 SaaS 的订单链路测试仓库（Java 17 + JUnit 5 + Testcontainers），约 2100 个用例、18 万行测试代码。做了一次 grep：

• new Order( 出现 1243 次
• "20001"（一个商品 SKU 字符串）出现 96 次
• setAmount(99.9) 出现 312 次
• 硬编码的手机号、地址、状态码合计 约 2600 处

后果是：业务方把「订单金额」从 Double 改成 BigDecimal 时，编译挂了 38 处；更糟的是测试数据在 47 个文件里各自为政——同一个「已支付订单」在 A 文件里状态是 PAID，在 B 文件里是 PAY_SUCCESS，导致 3 个用例长期假绿。这不是「写得多」的问题，是没有单一数据源的问题。

二、原理与根因：为什么数据会散落

根因就一条：用例的「意图」和「数据构造」耦合在一起了。

• 测试框架（JUnit）只关心「给一个对象、断言一个结果」，它不关心对象怎么造。
• 于是每个用例作者都顺手 new 一遍，把业务字段的取值规则复制进用例里。
• 一旦字段语义变化（类型、枚举、校验规则），变化点就散落在 N 个用例中，修改半径 = 用例数量，而不是 1。

解法不是「多用例复用」，而是把「怎么造一个合法对象」从用例里抽出来，收敛到一个可复用、可覆写、可默认化的数据工厂里。这样修改半径回到 1，且默认值统一。

三、具体做法：Builder + 默认值 + 覆写

核心三步：默认值、可覆写、按场景提供 preset。

public final class OrderBuilder {
    private Long id = 1001L;
    private String sku = "20001";          // 单一来源
    private BigDecimal amount = new BigDecimal("99.90");
    private OrderStatus status = OrderStatus.PAID;  // 统一用 PAID
    private String phone = "138****0000"; // 脱敏默认值

    public OrderBuilder id(Long id)      { this.id = id; return this; }
    public OrderBuilder sku(String sku)  { this.sku = sku; return this; }
    public OrderBuilder amount(BigDecimal a){ this.amount = a; return this; }
    public OrderBuilder status(OrderStatus s){ this.status = s; return this; }

    public Order build() {
        return Order.of(id, sku, amount, status, phone);
    }
    // 场景 preset：一行表达意图
    public static OrderBuilder paid()   { return new OrderBuilder(); }
    public static OrderBuilder unpaid() { return new OrderBuilder().status(OrderStatus.CREATED); }
}

用例里就从「7 行构造」变成「1 行意图」：

// 之前
Order o = new Order(1001L, "20001", 99.9, "PAID", "13800000000");
// 之后
Order o = OrderBuilder.paid().build();
Order o2 = OrderBuilder.unpaid().sku("30002").build();

收口后的量化收益（一周内）：

• grep "new Order(" 从 1243 → 41（剩下的是工厂内部与个别需要显式构造的边界用例）
• 金额类型从 Double 改 BigDecimal 的改动点从 38 → 1（工厂字段声明处）
• 状态枚举假绿用例从 3 → 0

四、踩过的坑与反直觉之处

1. 工厂别做成「上帝对象」。给所有字段都开 setter 会退化成 new 的另一种写法。原则：只暴露语义相关的字段，其余锁死为默认值。
2. 默认值必须是「合法且自洽」的。我们踩过坑：默认 status=PAID 但默认 amount=0，导致一批「已支付订单金额校验」用例莫名失败，排查半天。默认组合要能独立通过业务校验。
3. 别在工厂里连数据库。工厂只造内存对象；持久化交给 Testcontainers 的 fixture 层。混在一起后，单测被迫起了容器，耗时从 0.4s 涨到 2.3s。
4. 敏感数据务必脱敏默认值。手机号、身份证用 138****0000 这类占位，禁止在仓库里出现真实号码（引用他人数据时同理，脱敏为 [已脱敏]）。
5. 反直觉：工厂不是「为了复用」，而是「为了把修改半径从 N 压到 1」。哪怕某个对象只被一个用例用到，只要它是业务实体，就应该走工厂。

五、结论与可复用清单

把「数据怎么造」从用例里抽出来，是可维护性投入里性价比最高的一档——它不改变测试覆盖，只改变修改成本。

可复用清单：

• [ ] grep 统计 new Xxx( 与硬编码魔法值数量，建立基线
• [ ] 为每个核心业务实体建一个 XxxBuilder，默认值「合法且自洽」
• [ ] 提供 2–3 个语义 preset（paid()/unpaid()），用例用意图而非字段
• [ ] 工厂只造内存对象，持久化交给 fixture/容器层
• [ ] 敏感字段默认脱敏值，仓库内禁真实号码
• [ ] 改完跑一次 grep，目标：魔法值下降 ≥80%，字段类型改动点 = 1

一句话：用例表达意图，工厂负责构造，默认值保证自洽。