程序演变和破碎测试

Question

维持单元测试很困难.我确信我们都经历过一个时刻,对被测系统的看似微小的变化导致数十个单元测试失败.有时这些故障揭示了SUT中的错误,但通常测试已经过时,不再反映SUT的正确行为.在这些情况下,有必要修复损坏的测试.

你遇到过这种情况吗？经常发生吗？你介绍了什么变化以及失败是如何表现出来的？你修复了破损的测试或者只是删除了它们吗？如果是前者,怎么样？如果是后者,为什么？对失败的恐惧如何影响您编写测试的愿望？

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

Answer 1

当您意外破坏代码时,是不是单元测试的全部内容告诉您？我永远不会删除失败的测试,除非它正在执行将从我的系统中删除的代码; 您必须将测试创建和维护视为编写软件的一个组成部分,与交付的代码一样重要.

Answer 2

对失败的恐惧如何影响您编写测试的愿望？

对失败的恐惧是我编写考试的愿望.一个测试套件让我立即反馈我的最后一次更改是否破坏了什么,以及它破坏了什么.害怕是改变你的代码,不知道事情是否有效.

Answer 3

维持单元测试很困难.

True enough. The co-evolution of production code and test code together is hard. Both kinds of code shares similiarities (e.g. naming convention), but they still differ in nature. For instance the DRY can be violated in test code if necessary; code duplication would indeed be found easily as test would break in both place. The tension between test and production code results sometimes in specific design trade-off (e.g. dependency injection) to ease testability. Again, these tensions are relatively new, and the relationship between the design on production code and the effort in maintenance is not well understood. The article "On the interplay between software testing and evolution" is great (I was not able to find it in PDF, but didn't google for a long time).

我确信我们都经历过一个时刻,对被测系统的看似微小的变化导致数十个单元测试失败.有时这些故障揭示了SUT中的错误,但通常测试已经过时,不再反映SUT的正确行为.在这些情况下,有必要修复损坏的测试.

缺陷定位 - 测试套件精确定位缺陷的能力 - 也只是部分理解.设计测试套件导致高缺陷本地化的最佳策略是什么并不清楚.大多数测试在它们之间有一些重叠,这导致低缺陷定位.订购测试使他们相互依赖改善了这方面,但同时违背了孤立测试的原则.我们看到人们越来越意识到这种紧张局势,但解决这些问题并没有明确的解决方案.这是一篇关于利用测试之间的依赖关系的文章.

的问题,过时或不相关的测试(那些谁不包括在最后的任何东西)也日益认识.测试覆盖率不够,高质量的测试套件需要经验,或者至少需要一些教育.请参阅这篇关于100%覆盖率神话的文章.

对失败的恐惧如何影响您编写测试的愿望？

您必须在(1)投入测试套件的初始时间(2)维护工作和(3)测试套件的有效性之间找到平衡点.我主要写的是我所说的"拐点测试",这里是我对这个主题的看法.