unit-testing - 管理单元测试的维护负担

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

3年前关闭。




Improve this question




编码测试优先，我发现我的代码中可能有 3/4 是单元测试；如果我真的很极端，除了修复失败的单元测试之外不写一行代码，这个比例会更高。维护所有这些单元测试会增加代码更改的大量惯性。早些时候，我把它吸起来并修复它们。一有压力，我就收到了 broken_unit_tests目录重新访问“当有时间”。感觉 TDD 过早地实现了高覆盖，在设计还没来得及具体化之前。

我如何找到摆脱这种困境的方法，并开始像我应该的那样欢迎不断变化的需求？

Answer 1

将程序员纪律的方面放在一边......(如果你可以在不进行伙伴构建或不修复所有测试的情况下进行检查，这是个人的事情。敏捷假设高度纪律......以及勇气和支持保持在正确的道路上在压力之下 :)，

如果您发现进行单个更改未能通过多个测试，则表明您的测试有问题。 脆弱测试 当您开始使用 TDD 时很常见……如果您花更多的时间修复测试而不是修复代码……停下来，喘口气并反射(reflection)。解决疾病而不是症状。
如果你有一些代码片段，我们可以讨论。就目前而言，我不认为我可以帮到你太多...
指南:测试失败的原因只有一个。相反，每个失败的测试都应该指出缺陷的确切唯一位置。两个测试不应该因为相同的变化而失败。
除非您进行架构级别的彻底更改，否则这种情况应该很少见。