采用TDD开发遇困惑：重构代码时现有测试用例全部失效

我完全懂这种挫败感——刚上手TDD时，每次重构代码就得跟着改一堆测试，感觉不仅没提高效率，反而拖慢了节奏，真的很闹心。你遇到的核心问题，大概率是测试用例太关注代码的内部实现细节，而不是业务行为。

为什么你的测试会在重构时集体失效？ #

拿你给出的SalaryManager类来说，如果你的测试盯着tempSalary这类中间变量、或者if分支的具体逻辑来写，那只要你重构时调整了这些内部实现（比如把tempSalary合并到salary的计算里，或者优化了条件判断的顺序），测试就会直接失效——但实际上，你的业务逻辑（计算工资并返回消息）根本没变化，只是实现方式变了。

怎么调整才能让测试更健壮？ #

这里给你几个实用的方向：

• 把测试聚焦在业务行为上，而非内部实现
  测试应该验证的是“输入X，输出是否符合预期的业务结果”，而不是“方法里用了什么变量、走了哪个分支”。比如针对CalculateSalaryAndSendMessage，你应该测试：

  当用户工作22天（满勤）、月薪5000时，返回的消息内容是包含“5000元”的正确提示；当工作10天时，返回的是按比例折算后的薪资消息。
  而不是去测试tempSalary的具体数值，或者if条件的执行路径。

• 用测试替身隔离外部依赖
  如果CalculateSalaryAndSendMessage里实际涉及到发送消息的外部服务（比如邮件、短信接口），一定要把这部分依赖抽象成接口（比如IMessageSender），测试时用Mock对象来代替真实服务。这样你重构薪资计算逻辑时，完全不用碰消息发送相关的测试，只要保证计算结果正确就行。

• 小步重构+频繁跑测试
  重构时别想着一步到位，拆成极小的改动：比如先把冗余的tempSalary变量删掉，跑一遍测试确认没问题；再优化if的条件判断，再跑测试。这样就算有测试失效，也能快速定位到是哪一步改出的问题，不会一下子面对一堆红色失败。

举个具体的测试对比例子 #

❌ 容易失效的坏测试（盯着实现细节）：

[Test]
public void CalculateSalaryAndSendMessage_TempSalaryMatchesExpected()
{
    var manager = new SalaryManager();
    // 直接访问内部变量，重构时改了变量名或计算逻辑就失效
    manager.CalculateSalaryAndSendMessage(22, 5000);
    Assert.AreEqual(5000, manager.tempSalary);
}

✅ 健壮的好测试（聚焦业务行为）：

[Test]
public void CalculateSalaryAndSendMessage_FullWorkDays_ReturnsFullSalaryMessage()
{
    var manager = new SalaryManager();
    var result = manager.CalculateSalaryAndSendMessage(22, 5000);
    
    // 只验证最终输出是否符合业务预期
    Assert.IsTrue(result.Contains("您的本月薪资为5000元"));
    Assert.IsTrue(result.Contains("已发送薪资通知"));
}

最后想说的 #

TDD的价值其实是在长期的迭代和重构中体现的——当你的测试都盯着业务行为时，重构代码会变得非常有底气：只要测试全绿，就说明业务逻辑没被破坏。初期的效率下降是因为还没找到正确的测试姿势，调整过来之后，你会发现TDD反而能帮你避免很多重构引入的bug，整体效率其实是提升的。

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