首先编码测试，我发现我的代码中可能有3/4是单元测试;如果我真的是极端的，除了修复失败的单元测试之外没有编写一行代码，这个比例会更高。维护所有这些单元测试会增加代码更改的大量惯性。在早期，我把它吸了起来并修复它们。一旦有压力，我最终得到一个broken_unit_tests目录，以便在有时间时再次访问。在设计有时间结晶之前，感觉TDD过早地进行了高覆盖率。
我如何找到摆脱这种困境的方法，并开始欢迎像我应该的那样改变需求？
答案 0 :(得分：10)
保持程序员纪律的一面......（如果你没有做好伙伴建立或没有修复所有测试就可以办理登机手续，这是个人的事情。敏捷承担高度纪律......勇气和支持在压力下保持正确的道路：），
如果您发现单次更改无法通过多次测试，那么您的测试就会出现问题。当您开始使用TDD时，脆弱的测试很常见......如果您花费更多时间来修复测试而不是修复代码...停止，呼吸和反思。修复疾病而不是症状
如果你有一些代码片段，我们可以讨论。目前我不认为我可以帮助你很多...
指南：测试应该失败只有一个原因。相反，每个失败的测试都应该指出缺陷的确切唯一位置。由于相同的变化，两个测试不应该失败。
除非你进行架构级别的彻底改变，否则这应该是罕见的。
答案 1 :(得分：8)
我认为你已经反过来了。当实施可能破坏单元测试的更改时，您应该首先更新单元测试。这样你就不会得到破碎的单元测试和工作代码。您将要么进行失败的单元测试，因为代码尚未就绪，或者两个部分都能正常工作。
如果您认为这是一个开销，只需考虑一下您将来可以节省错误修复的时间。
你也可以尝试在短周期内工作。即而不是
尝试
当有一个截止日期迫在眉睫，经理人肩负着时，很难通过大量积压的单元测试。当你养成习惯时，同时进行代码和测试很容易。
答案 2 :(得分：3)
单元测试应该是完全不可变的。
如果您正在编写测试，编写代码以使测试通过，并打破其他测试，则应将新代码视为“错误”。
现在显然，在某些情况下，如果更改API合同，您可能需要重写测试，但在大多数情况下，您不应该将“重写测试”视为执行TDD的有效方法。
答案 3 :(得分：1)
我想这个想法是抛弃不再测试适当行为的单元测试并编写新的单元测试。 以一种反映行为而不是实现的方式编写单元测试也是很好的。所以他们将更加独立于设计。
一般来说，我不是TDD的拥护者。 ：）
答案 4 :(得分：1)
您的测试可能不够集中，或者您的系统中存在太多依赖项。
当我改变我的代码非常重要的方面时，我大部分时间都在做的是开发一个新的测试套件来进行我的更改，但不会破坏旧的，所以软件以新老方式工作并行，一旦我对我的重构感到满意，我会删除旧方法代码和旧方法的测试。
不确定它是100％明确的......