我正在为自己维护的应用程序开发自动回归测试套件。在开发自动回归测试时，我遇到了一些几乎可以肯定是错误的行为。因此，到目前为止，我已经修改了自动回归测试以不记录失败-我的意思是故意允许这种不良行为过去。

因此，我对这个网站上其他人的意见很感兴趣。显然，我将在缺陷跟踪中添加一个错误，以确保纠正此错误行为。但是，是否有任何令人信服的理由(以任何一种方式)改变回归测试以不断表明失败，或者让回归测试失效并且直到我们能够修复有缺陷的行为时才失败？我认为这是另一种问题中的六分之一，但我在这里提出问题是因为我认为其他人可能会有不同的看法。

@Paul Tomblin，

只是要清楚一点-我从未考虑过删除测试；我只是在考虑修改通过/失败条件，以允许失败，而不会在每次运行测试时都将其抛出我的脑海。

我有点担心已知原因引起的重复失败，最终会像C ++中的警告一样被对待。我知道开发人员会在他们的C ++代码中看到警告，而只是忽略它们，因为他们认为它们只是无用的噪音。恐怕在回归套件中留下已知的故障可能会导致人们开始忽略其他(可能更重要的)故障。

顺便说一句，以免我被误解了，我认为C ++中的警告是编写强大代码的重要帮助，但从我遇到的其他C ++开发人员看来，我认为我是少数。

解决方案

回答

如果停止测试，我们将如何知道它何时修复，更重要的是，我们如何知道它是否再次损坏？我反对进行测试，因为我们可能会忘记再次将其重新添加。

回答

我会说："是的！"。一个简单的事实是，它会失败吗？是的！然后应该将其记录下来。通过允许失败的测试通过，我们几乎在损害测试。

我个人会担心的一件事是，如果我这样做并乘了公共汽车，那么"补丁"可能不会被删除，这意味着即使在"错误修复"之后，该错误仍可能会保留。

放下它，更新项目说明，甚至降低严重性(如果可能)，但一定不要破坏正在检查损坏的东西的东西；)

回答

如果未按预期执行操作，则应该仍然失败。

否则，很容易忽略。保持简单-它起作用或者不起作用。失败或者成功:)

-凯文·费尔柴尔德(Kevin Fairchild)

回答

测试失败是一种磨擦。破损的代码和未完成的代码之间有区别，是否应立即解决测试取决于失败的测试所暴露的情况。

如果它损坏了，我们应该尽快修复它，而不是稍后修复。如果未完成，请在有时间时处理。

无论哪种情况，显然我们都可以忍受它表现不佳(暂时)，因此，只要记录下该问题，我们最好不要让它困扰我们，直到我们有时间修复它为止。

回答

尽管我同意Paul的大部分观点，但争论的另一面是严格地说，回归测试应该测试程序行为的变化，而不仅仅是任何旧的错误。特别是当我们破坏了以前有用的东西时，它们应该告诉我们。

我认为这可以归结为在此应用上运行其他类型的测试。如果我们有某种类型的单元测试系统，那么可能比在回归测试中更适合进行此测试(至少在修复错误之前)。但是，如果回归测试是我们唯一的测试，那么我可能会将测试保留在原位。

回答

我们在单元测试中添加了"延后"功能。这样就可以在测试中添加一个属性，该属性的基本含义是"从此日期开始X周内忽略失败"。开发人员可以注释一个他们知道暂时不会修复的测试，但是将来不需要任何干预来手动重新启用它，该测试将在指定时间简单地弹出测试套件。