在调试或添加新功能时，管理旧单元测试的最佳实践是什么？

Question

我正在尝试了解管理较旧的单元测试的最佳方法是什么，由于代码中的错误或逻辑更改等原因而无法真正匹配或继续工作？ 我们是否只是跳过它们并修改它们以适应当前的逻辑？

例如，如果这些测试不是由您编写的，那么现在您负责修改代码。在继续之前，您是否仍然花时间更新这些测试以使其通过？

或者只是跳过它们？ 感谢。

Answer 1

过时的单元测试没用。如果您希望它们有用，请更新它们。

Answer 2

当然你应该花些时间让它们通过。 为什么抛弃这项工作呢？

TDD的整个想法是让所有测试都一直通过。从你开始说“嘿，这个单元测试失败就可以了”的那一刻起，TDD就没用了。它需要一些纪律，是的，但最终还是值得的。

Answer 3

当测试失败时，有三个选项：

1. 生产代码已损坏，需要修复。
2. 测试中断（或者最近更改了生产代码），测试需要修复。
3. 不再需要测试指定的行为，并且可以删除测试。

在编写任何新代码之前，所有测试都必须通过。测试失败时，您必须立即修复它们，或还原您的更改。否则，您无法确定测试失败时，是否是因为您在一分钟前所做的更改，还是仅仅是误报。

忽略失败的测试是通往黑暗面的途径。如果你长时间忽略它们，测试套装会腐烂，因为更多的测试失败了，它将失去它的价值，你需要抛弃测试。然后当你再也不能依赖测试套件时，你会毫不犹豫地改进生产代码的设计，而且生产代码也会开始腐烂。最后，维护生产代码不再可能，你需要抛弃它并重写它。

Answer 4

  

例如，如果那些测试不是   你写的，现在你在   收费修改代码。你呢   仍然花时间更新这些   在继续前进行测试以使其通过？

我会更新测试。

但首先我会追捕破坏他们的开发人员......好here's some inspiration。

Answer 5

每次我处于类似情况时，都会匆匆忙忙地认为过时的测试不存在。因此，我将代码视为legacy code，并且仅为我正在处理的功能编写新测试。

Answer 6

有两种可能的情况：

1. 少数测试失败 - 修复测试
2. 大部分测试失败，您需要花费更多时间来修复所有测试然后实施更改 - 删除整个测试项目并编写新测试。

Answer 7

进行失败的测试是绝对不可接受的。您的系统应该拒绝任何没有每次测试通过的机会，或者至少一个失败的测试应该向开发人员触发导致测试失败的优先级工作任务。

随着时间的推移，测试确实已经过时，特别是对于成熟的产品。充其量只是简单地运用代码。有时他们会失败，但通常是出于与他们为什么一开始就写的原因无关的原因。您必须判断是否丢弃过时的测试。我们有10,000次测试，如果我们偶尔不会砍掉死木，测试需要很长时间才能完成。

测试覆盖率工具可以帮助您确定是否值得保留任何特定测试。