TDD 与可维护性

这一课你将能做到

1. 独立走完一轮「红 → 绿 → 重构」，为注册校验规则留下可运行的测试
2. 用「先写复现测试再修 bug」处理线上缺陷，证明修复的同时钉死回归
3. 判断何时坚持严格 TDD、何时先探索再补测，并对遗留代码写出「表征测试」

为什么要学

测试若总是「功能写完再补」，容易变成只护 happy path 的事后作业。TDD 把顺序反过来：先写一个失败的用例（红），再写刚好够用的实现（绿），最后在绿测保护下整理结构（重构）。人话：先约定「调用方想要什么」，再长出实现——测试不是验收单，是设计工具。

以 CodeForge 的用户注册为例：AuthService.register 里用户名 3–32 位、邮箱格式、密码 6–64 位、重复拒绝——每条规则都值得被一个红测钉住再实现。修线上 bug 时（比如「邮箱大小写不同竟能重复注册」），「先写复现测试再修」几乎总是值得的。

两个常见误解先拆掉：一是「TDD = 先写完全部测试再写实现」——其实是极小步交替；二是「有测试就算 TDD」——从未红过的测试只是在给已有实现拍照，钉不住需求。你要练的是节奏感：每次只推进一个可观察行为。

先建立图像

     写失败测试
          │
          ▼
        【红】  ← 证明：需求被测试钉住了
          │ 最小实现
          ▼
        【绿】  ← 证明：行为达标
          │ 去重复 / 改名 / 抽方法
          ▼
       【重构】 ← 证明：结构变好且仍绿
          │
          └──► 下一个小行为，再红…

原则	人话
一个测试一个行为	红灯时立刻知道哪条规则坏了
测试像文档	方法名说出前提与期望
测试里少逻辑	少 if/for，多用参数化
金字塔一致	TDD 主战场在单元层，不是 E2E

时间盒控制节奏：

步	建议时长	超时信号
红	几分钟写出失败断言	半小时写不出 → 需求太大，再切片
绿	几分钟到一刻钟	大段新代码才绿 → 步子大了，回拆
重构	有绿测再整理	想改行为 → 停，先改测试

跟着做

步骤 1：选一个小行为，先写红测

需求：注册用户名规则（镜像本站 AuthService：3–32 个字符，首尾空格忽略）。先建练习类 UsernameRules，此刻它还不存在——先写测试：

import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.*;

class UsernameRulesTest {

    @Test
    void 合法用户名标准化后返回() {
        // 此刻 UsernameRules 还没写：编译失败也是一种「红」
        assertThat(UsernameRules.normalize("  neo  ")).isEqualTo("neo");
    }
}

mvn test -Dtest=UsernameRulesTest

应看到：编译错误或断言失败。若已经绿，说明你测的是已有实现——换一条尚不存在的规则，保证经历「红」。

步骤 2：最小实现变绿

public class UsernameRules {
    public static String normalize(String raw) {
        return raw == null ? "" : raw.trim();
    }
}