让测试跑得快、活得久

测试的读者,是未来那个 debug 的人

写产品代码时,你的读者是"未来的维护者"。写测试时,读者更具体:是那个盯着 CI 一片红、想搞清楚哪儿坏了的人。所以测试的第一美德不是"聪明",是清楚。这条原则,推出了下面几乎所有的做法。

DAMP,而不是 DRY

产品代码奉行 DRY(Don't Repeat Yourself,别重复)。但测试代码,有一条几乎相反的准则:DAMP(Descriptive And Meaningful Phrases,描述性、有意义)。

当然,这不是说测试里所有重复都好。有一种重复该消除 —— 那些又长又没信息量的对象构造。解法不是藏进辅助方法,而是测试数据构造器。

测试数据构造器:让 Arrange 一眼看懂

看一个典型的痛点:测试需要一个 User,但 User 有十个字段,而这个测试只关心其中一个(age)。天真的写法把无关字段全列出来,淹没了重点:

// ✗ 噪音淹没重点:这个测试其实只关心 age
val user = User(1, "Ann", "ann@x.com", "13800000000",
                Address("...", "..."), Role.NORMAL, true, 0, now(), now())

// ✓ 构造器 + 默认值:只写出你关心的那个字段
val user = aUser().withAge(17).build()   // 其余字段都是合理默认值

一个失败,一眼定位

可维护性的另一半,是失败时它有多好懂。这里把前面几章的相关点收拢成一组规矩:

• 好名字(第 2 章):失败列表里,一个"给定-当-则"的名字直接告诉你哪个行为坏了。
• 一个失败理由(第 2 章):一个测试只测一件事,红了就知道是哪件,不用挨个注释去试(断言轮盘)。
• 会说话的断言(第 2 章):assertEquals / assertThat 而非 assertTrue,失败信息直接给出期望和实际。
• 失败信息带上下文:必要时用 .describedAs("八折后价格") / clue("..."),让红出来的那行自解释。

这些加起来的效果是:一个测试红了,你看一眼失败列表和信息,就知道发生了什么、去哪儿找 —— 不用打开测试代码、不用加日志、不用重跑。这个"一眼定位"的体验,是可维护测试和折磨人测试的分水岭。

别怕删测试

人们对删测试有种莫名的敬畏,好像测试越多越好。不对。

速度:必要的慢,和你自找的慢

第 4 章讲过速度是测试的生死线。到了维护阶段,要区分两种慢:

大部分"测试套太慢",不是必要的慢,是一堆自找的慢累加起来的。逐个消除它们,通常能把一套 10 分钟的测试压到 1 分钟以内 —— 而快,直接决定了这套测试会不会被频繁跑、会不会活下去。

AI 与测试维护

构造器怎么写:默认值 + 链式覆盖

测试数据构造器的实现,在 Kotlin 里很轻。用带默认值的工厂函数,或一个小 builder:

// 最简版:一个带默认值的工厂函数就够了
fun aUser(
    id: Int = 1,
    name: String = "测试用户",
    email: String = "test@x.com",
    age: Int = 30,
    role: Role = Role.NORMAL,
) = User(id, name, email, age, role /* ... 其余字段都有合理默认 */)

// 用的时候只写你关心的:
val teen = aUser(age = 17)                    // 这个测试关心"未成年"
val admin = aUser(role = Role.ADMIN)          // 这个测试关心"管理员"
val ann = aUser(name = "Ann", email = "ann@x.com")

自定义断言:让失败信息说业务语言

可读性还能再进一步。当你反复断言同一组条件,可以封一个领域断言,让测试和失败信息都说人话:

// 封装一个业务语义的断言
fun assertIsPaidOrder(order: Order) {
    assertThat(order.status).isEqualTo(OrderStatus.PAID)
    assertThat(order.paidAt).isNotNull()
}

// 测试里读起来像需求:
@Test fun `支付成功后订单已支付`() {
    val order = service.pay(anOrder())
    assertIsPaidOrder(order)     // 一行,语义清晰,失败信息也精确
}

注意这和「把 setup 藏进辅助方法」不同 —— 这里抽走的是断言(一组反复出现的、有明确业务含义的检查),而且它让失败信息更清楚,不是更模糊。抽象得对不对,判据始终是:它让测试更好读、失败更好懂了,还是更难追了?

命名约定:让失败列表成为一份文档

第 2 章说过好名字的重要性,这里给一套可以团队统一的约定。挑一种坚持用:

关键不是选哪种,是全队一致、且名字里含足够信息。当 CI 挂了 40 个测试,一列清晰的名字能让你不打开任何代码,就大致知道「是优惠模块的边界处理集体出问题了」。名字排在一起,本身就是一份活的行为规格 —— 这是命名之外的额外红利。

最后一章了。我们回到起点 —— 回到第 1 章那段 AI 写的、看起来完美的代码。把全书压成一张你能在写代码时当场用出来的判断表:什么该测、什么不该测、测到哪一层。以及一个诚实的收尾。