正确实践Test Driven Development时如何避免投机通过单元测试？

核心问题本质 #

你遇到的是TDD入门阶段非常典型的认知偏差：把TDD单步迭代的中间结果，当成了完整流程的最终交付产物，TDD本身的设计已经包含了避免这类问题的机制。

首先要明确：硬编码返回5的实现是合理的中间步骤，不是错误 #

TDD的「绿」阶段要求你写最少的代码让测试通过，这个规则的目的是避免你提前过度设计，在只有一个测试用例的前提下，返回5确实是满足要求的最少代码，这一步操作完全符合TDD规范，问题出在你没有继续走完后续的迭代流程。

TDD本身的迭代机制会自动倒逼出正确实现 #

TDD的完整流程不是写一个测试、过了就结束，而是「红-绿-重构」循环往复，直到所有需求场景都被覆盖：

1. 你写完第一个测试AddingTwoAndThreeEquals5，运行测试变红（还没实现Add方法）
2. 写return 5的实现，测试变绿
3. 这时候你清楚当前实现只满足单个测试的硬编码要求，所以你需要新增第二个测试用例，比如：

[TestMethod]
public void AddingOneAndOneEquals2()
{
    var myCalulator = new Calculator();
    var result = myCalulator.Add(1, 1);
    Assert.AreEqual(2, result);
}

4. 运行新测试，原来的return 5实现直接变红，你必须修改实现才能同时过两个测试，这时候最省事的写法就是return a + b
5. 如果你还担心有问题，可以继续补充边界场景的测试：比如0+0、负数相加、int最大值相加等，所有测试覆盖后，根本不可能存在硬编码的空间。

配套的TDD实践进一步规避这类问题 #

• 三角验证原则：这是TDD的标准实践，对于逻辑输出类的功能，至少要有两个不同输入的测试用例，才能证明实现是通用的，而非硬编码特定结果。
• 重构阶段的合理性校验：绿阶段之后的重构环节，除了清理冗余代码，还要检查实现逻辑的合理性：如果一个Add方法里出现硬编码的返回值，哪怕所有当前测试都过，也属于需要优化的不合理实现，调整后再跑测试验证即可。

辅助保障手段 #

你提到的代码评审确实是最后一道防线，但实际场景中这类投机实现根本不需要走到评审环节：如果要硬编码满足10个不同输入的加法测试，需要写10个if分支，开发成本远高于直接写正确的加法实现，正常开发者都不会做这种得不偿失的操作。

内容的提问来源于stack exchange，提问作者gentleGiantFan