我试图了解管理由于代码中的错误或逻辑更改等原因而不再匹配或不再有效的旧单元测试的最佳方法是什么?我们是否只是跳过它们并修改它们以适应当前逻辑?
例如,如果这些测试不是由您编写的,而现在您负责修改代码。在继续之前,您是否仍然花时间更新这些测试以使其通过?
或者只是跳过它们?谢谢。
我试图了解管理由于代码中的错误或逻辑更改等原因而不再匹配或不再有效的旧单元测试的最佳方法是什么?我们是否只是跳过它们并修改它们以适应当前逻辑?
例如,如果这些测试不是由您编写的,而现在您负责修改代码。在继续之前,您是否仍然花时间更新这些测试以使其通过?
或者只是跳过它们?谢谢。
过时的单元测试毫无用处。如果您希望它们有用,请更新它们。
当然,您应该花时间让它们通过。为什么要扔掉这项工作?
TDD 的整个想法是让所有测试始终通过。从你开始说“嘿,这个单元测试失败没关系”的那一刻起,TDD 就毫无用处。它需要一些纪律,是的,但最终还是值得的。
当测试失败时,有三个选项:
在编写任何新代码之前,必须通过所有测试。当测试失败时,您必须立即修复它们,或者恢复您的更改。否则你无法确定测试失败是因为你一分钟前所做的更改,还是只是虚惊一场。
忽略失败的测试是通往黑暗面的道路。如果你忽略它们的时间足够长,测试服将会随着更多的测试失败而腐烂,它会失去它的价值,你需要把测试扔掉。然后当你不能再依赖测试套件时,你会犹豫改进生产代码的设计,生产代码也会开始腐烂。最后,不再可能维护生产代码,您还需要将其丢弃并重写。
每次我遇到类似的情况时,都会如此着急,以至于我认为过时的测试不存在。因此,我将代码视为遗留代码,我只为我正在处理的功能编写新测试。
那里有两种可能的情况:
考试不及格是绝对不能接受的。你的系统应该拒绝任何没有通过每个测试的机会,或者至少一个失败的测试应该触发开发人员的优先工作任务,导致测试失败。
随着时间的推移,测试确实会变得过时,特别是对于成熟的产品。它们充其量只是为了简单地练习代码。有时它们会失败,但通常与最初编写它们的原因无关。您必须自行判断是否丢弃过时的测试。如果我们不偶尔砍掉那些测试需要很长时间才能完成的枯木,我们就有 10,000 次测试。
测试覆盖率工具可以帮助您确定任何特定测试是否值得保留。