反模式图鉴:十种「测了个寂寞」

一张速查表

先给全景,再逐个细说重点的几个:

①②③④⑧⑨⑩ 前面都展开过了,这里补讲三个没细说、又特别隐蔽的:重言式、神秘嘉宾、过度精确。

⑤ 重言式:测试和实现,犯同一个错

这是最阴险的一种,因为它永远绿,而且看起来很认真。问题出在期望值是怎么来的:

// 被测实现(有 bug:漏了闰年)
fun daysInFebruary(year: Int): Int = if (year % 4 == 0) 29 else 28

// 重言式测试:用一模一样的逻辑算期望值
@Test fun `二月天数`() {
    val expected = if (2100 % 4 == 0) 29 else 28   // ← 抄了实现的逻辑!
    assertEquals(expected, daysInFebruary(2100))    // 永远绿,哪怕都错了
}

⑥ 神秘嘉宾:测试依赖看不见的外部东西

一个测试读起来完整,但它其实偷偷依赖一个不在测试里、你也看不见的东西 —— 一个外部文件、一条数据库记录、一个网络服务、一个环境变量。

@Test fun `解析用户`() {
    val json = File("/data/fixtures/user.json").readText()  // ← 神秘嘉宾
    val user = parse(json)
    assertEquals("Ann", user.name)   // 为什么是 Ann?看这个测试根本不知道
}

⑦ 过度精确:断言了太多你不在乎的东西

和"没有断言"相反的另一个极端:一个测试断言了一大堆和它的主旨无关的细节,于是任何无关的改动都让它红。

// 这个测试想验证"注册成功",却顺手断言了一堆无关细节
@Test fun `注册成功`() {
    val user = service.register("ann@x.com")
    assertEquals("ann@x.com", user.email)
    assertEquals(User.Role.NORMAL, user.role)
    assertEquals("2026-07-12T10:30:00.123Z", user.createdAt)  // ← 精确到毫秒?!
    assertEquals(0, user.loginCount)
    assertEquals("#4A90D2", user.avatarColor)                 // ← 关注册什么事
}

共同的病根

把这十种排一排,你会发现它们其实归为两大类病根:

AI 时代:它是这份图鉴的高产作者

三个「测试代码里的坏味道」

前面几条讲的是「测得不对」。还有一类是「测试代码本身写得像坨浆糊」—— 它们在 code review 里最该被拦下。

测试里有逻辑

测试代码里出现了 if、for、when,是个强烈的警报:

// ✗ 测试里有分支:哪条路径跑了?不确定。逻辑对不对?没人测这个测试
@Test fun `折扣`() {
    for (total in listOf(50, 100, 150)) {
        val expected = if (total >= 100) total * 8 / 10 else total  // ← 重言式 + 逻辑
        assertEquals(expected, discount(total))
    }
}

这段同时犯了两条:循环 + 分支让你不知道哪个 case 真的跑了、红了是哪个;而那个 if 算期望值,又是重言式(抄了实现逻辑)。改法:拆成几个具体的、期望值写死的测试,或用参数化测试(@ParameterizedTest + 明确的「输入→期望」对照表)。测试代码应该是「一条直线」:摆输入、调、断言,没有分叉。

条件断言:悄悄什么都没测

// ✗ 如果 result 是 null,整个断言被跳过 —— 测试"通过"了,却什么也没验
@Test fun `查询`() {
    val user = repo.find(1)
    if (user != null) {
        assertEquals("Ann", user.name)   // user 为 null 时,这里根本不执行
    }
}

这个测试在 find 返回 null(一个 bug)时,会安静地绿 —— 因为 if 把断言跳过了。把条件去掉,让 null 直接炸:assertEquals("Ann", user!!.name) 或先 assertNotNull(user)。断言不该藏在 if 后面,否则那个「测了个寂寞」你根本发现不了。

DRY 过头:setup 藏进层层继承

和第 23 章呼应的反面:为了「不重复」,把 setup 抽进基类、抽进层层辅助方法,结果读一个测试得跳七八个文件。测试代码奉行 DAMP(描述性)而非 DRY —— 适度的重复,好过把意图藏到远处。一个测试红了,你应该能就地读懂它测什么,而不是去考古它的继承链。