编码测试优先，我发现我的代码可能有 3/4 是单元测试；如果我真的很极端，并且除了修复失败的单元测试之外没有编写任何代码，那么这个比率会更高。维护所有这些单元测试给代码更改增加了巨大的惯性。早些时候，我把它吸起来并修复它们。一旦有压力，我就会得到一个broken_unit_tests目录来重新访问“当有时间”。在设计有时间具体化之前，感觉就像 TDD 过早地实现了高覆盖率。
我如何找到摆脱这种困境的方法，并开始像我应该接受的那样迎接不断变化的需求？
问问题
1324 次
5 回答
10
将程序员纪律方面放在一边...（如果您可以在不进行伙伴构建或不修复所有测试的情况下进行签入，这是个人的事情。敏捷假设有严格的纪律.. 和勇气与支持保持在正确的道路上在压力之下 ：），
如果您发现进行单个更改未通过多次测试，则表明您的测试有问题。当您开始使用 TDD 时，脆弱的测试很常见……如果您花费更多时间修复测试而不是修复代码……停下来，呼吸和反思。解决疾病而不是症状。
如果你有一些代码片段，我们可以讨论。就目前而言，我认为我无法为您提供太多帮助...
指导方针：测试失败的原因只有一个。相反，每个失败的测试都应该指出缺陷的确切独特位置。两个测试不应由于相同的更改而失败。除非您正在进行架构级别的彻底更改，否则这应该很少见。
于 2008-10-16T12:29:30.917 回答
9
我认为你有相反的方式。在实施可能破坏单元测试的更改时，您应该首先更新单元测试。这样，您将永远不会得到损坏的单元测试和工作代码。您将有一个失败的单元测试，因为代码尚未准备好，或者两个部分都可以正常工作。
如果您认为这是一种开销，请考虑一下您将来会在错误修复上节省的时间。
您也可以尝试在短周期内工作。即代替
- 做很多改变
- 修复大量单元测试
- 重复
尝试
- 计划一个小改变
- 更改相关的单元测试
- 更改相关代码
- 重复
当最后期限迫在眉睫并且经理在你肩上时，你很难通过大量积压的单元测试。当您养成习惯时，同时编写代码和测试实际上很容易。
于 2008-10-16T12:25:30.300 回答
3
单元测试应该是相当不可变的。
如果您正在编写测试，编写代码以使该测试通过，并破坏您的其他测试，那么您的新代码应该被认为是“错误的”。
现在显然，在某些情况下，如果您更改 API 合同，您可能需要重写测试，但在大多数情况下，您不应该将“重写测试”视为执行 TDD 的有效方式。
于 2008-10-16T12:24:09.773 回答
1
我想这个想法是抛弃不再测试适当行为的单元测试并编写新的。以反映行为而不是实现的方式编写单元测试也很好。因此它们将更加独立于设计。
一般来说，无论如何我都不是 TDD 的拥护者。:)
于 2008-10-16T12:23:29.993 回答
1
您的测试可能不够集中，或者您的系统中有太多依赖项。
当我更改代码中非常重要的方面时，我大部分时间所做的就是开发一个新的测试套件来进行更改，但不会破坏旧的测试套件，因此该软件以新旧方式并行工作，一次我对我的重构很满意，我删除了旧方式代码和旧方式的测试。
不确定它是否100％清楚...
于 2008-10-16T12:28:24.507 回答