我最早接触 TDD 是在上一家公司。 当时团队 leader 定了条规矩：新功能必须先写失败测试。 我也跟着迷信，觉得不写红绿绿就是野路子。 坚持了大半年，把自己坑惨了，才开始怀疑这个教条。
有次做第三方账单解析引擎，需求是从各种邮件里提取金额。 我按照文档先写了几个用例，然后开始实现。 结果发现真实格式远比样例诡异，PDF转文字有乱码，日期写法五花八门。 我不得不反复回去改测试，因为测试的根本不是需求，而是我还没想明白的设计。 那段时间为了维持“先测试”的纯洁性，我大概有三分之一的精力都花在重写测试上。
后来翻回去细想，Kent Beck 当年提 TDD 时，脑中对接口和算法结构其实已经有比较清晰的轮廓。 它本质是一个设计工具，用测试把你一步步钉住，不至于跑偏。 但对于探索性的代码，这种钉住反而会变成一个笼子。 我现在更愿意先把 spike 写出来，验证路径能通，再把有用的行为补回成测试。 不是拒绝 TDD，而是拒绝无脑的顺序崇拜。
我还发现一个反直觉的点：TDD 带来的安全重构优势，只有在测试自身足够稳定时才能兑现。 我们团队后来有人 mock 成瘾，为了覆盖率把每个依赖都 mock 掉。 结果模块一拆分，测试和实现一起塌，修复测试又花了两天。 这种测试就不是资产，是标准的负资产。 早期业务方向天天变的时候，TDD 经常不是在护航，而是在拖着船不让你动。
最近我自己定了一个土判断标准：一段逻辑连续改动超过三次，而且每次测试都要跟着改， 说明我根本没把这块逻辑想透，这时候我会果断停止写测试，先把代码捋顺再说。 TDD 的核心价值是提供快速验证的小步子反馈循环，而不是“测试先写”这个动作本身。 工具是服务于人的，如果为了红绿循环把自己绕进去，那多少是有点本末倒置了。
