unit-testing - 程序演进和失败的测试

Question

维护单元测试很困难。我相信我们都经历过这样的情况:对被测系统的一个看似很小的更改会导致数十个单元测试失败。有时这些失败揭示了 SUT 中的错误，但通常测试已经过时并且不再反射(reflect) SUT 的正确行为。在这些情况下，有必要修复损坏的测试。

你遇到过这种情况吗？它经常发生吗？你引入了什么变化，失败是如何表现出来的？您是修复了损坏的测试还是简单地删除了它们？如果是前者，怎么办？如果是后者，为什么？对失败的恐惧如何影响您编写测试的愿望？

我还想找到破坏测试的具体例子。您是否知道任何以导致测试失败的方式发展的开源应用程序？

Answer 1

Maintaining unit tests is difficult.

没错。 生产代码和测试代码的共同进化是困难的。这两种代码有相似之处(例如命名约定)，但它们在本质上仍然不同。例如，如有必要，可以在测试代码中违反 DRY；确实很容易发现代码重复，因为测试会在两个地方都中断。测试代码和生产代码之间的紧张关系有时会导致特定的设计权衡(例如依赖注入(inject))以简化可测试性。同样，这些紧张局势相对较新，生产代码设计与维护工作之间的关系还不是很清楚。文章“On the interplay between software testing and evolution”很棒(我没能找到它的 PDF 版本，但谷歌了很长时间没有找到)。

I am sure that we all have experienced a time when a seemingly small change to the system under test caused dozens of unit tests to fail. Sometimes these failures reveal bugs in the SUT, but often the tests are out of date and no longer reflect the correct behavior of the SUT. In these cases, it is necessary to fix the broken tests.

缺陷定位 - 测试套件精确定位缺陷的能力 - 也只被部分理解。设计导致高缺陷定位的测试套件的最佳策略是什么尚不清楚。大多数测试在它们之间有一些重叠，这导致低缺陷定位。对测试进行排序使它们相互依赖改善了这方面，但同时违背了隔离测试的原则。我们看到越来越多的人意识到这种紧张局势，但没有解决这些问题的最终解决方案。这是一篇关于 exploiting dependencies between tests 的文章.

过时或不相关的测试(那些最后没有涵盖任何内容的测试)的问题也在不断提高。测试覆盖率不够，高质量的测试套件需要经验，或者至少需要一些教育。请参阅有关 the 100% coverage myth 的文章.

How does the fear of failures affect your desire to write tests?

您必须在 (1) 投入测试套件的初始时间 (2) 维护工作和 (3) 测试套件的有效性之间找到平衡。我主要写的是我所谓的“拐点测试”，这里 my view关于这个问题。