我应该继续注册失败吗？

Question

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

所以，我对本网站上其他人的意见感兴趣。显然，我会在缺陷跟踪中添加一个错误，以确保修复此错误行为。但是，有任何令人信服的理由（无论哪种方式）要么改变回归测试以不断指出失败，要么让回归测试失败并且在我们能够修复有缺陷的行为之前没有失败？我认为这是另外一种问题中的一种，但我在这里问，因为我认为其他人可能会有不同的看法。

---

@Paul Tomblin，

只是要明确 - 我从未考虑过删除测试;我只是考虑修改通过/失败条件以允许失败，而不是每次我运行测试时它都被扔到我的脸上。

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

BTW，以免被误解，我认为C ++中的警告是制作强大代码的重要辅助手段，但从我见过的其他C ++开发人员的角度来看，我认为我是少数。

Answer 1

如果你停止测试它，你怎么知道它何时被修复，更重要的是，你怎么知道它是否再次被打破？我不反对进行测试，因为你可能会忘记重新加入它。

Answer 2

我们在单元测试中添加了“贪睡”功能。这允许使用一个基本上表示“忽略此日期X周的失败”的属性对测试进行注释。开发人员可以注释一个他们知道暂时无法修复的测试，但是将来不需要任何干预来手动重新启用它，测试只会在指定的时间弹回测试套件。

Answer 3

我会说“好吧！”。简单的事实是，它失败了吗？是!然后它应该被记录。通过允许失败的测试通过，您几乎会损害您的测试。

我个人担心的一件事是，如果我这样做，并且在公共汽车下，那么“补丁”可能不会被删除，这意味着即使在“错误修正”之后，该错误仍可能仍然存在。

保留它，更新你的项目笔记，甚至可能会降低严重性（如果可能的话），但肯定不会破坏检查破碎的东西;）

Answer 4

如果它没有达到预期的效果，它应该仍然是失败的。

否则，它太容易被忽视了。保持简单 - 它有效或无效。失败或成功：）

- Kevin Fairchild

Answer 5

虽然我同意Paul所说的大部分内容，但争论的另一方面是严格来说，回归测试应该测试程序行为的变化，而不仅仅是任何旧的bug。当你破坏曾经工作过的东西时，他们会特意告诉你。

我认为这归结为此应用程序上运行的其他类型的测试。如果你有某种单元测试系统，那么这可能是一个更适合这个测试的地方，而不是在回归测试中（至少在修复bug之前）。但是，如果回归测试是您唯一的测试，我可能会将测试留在原地。

Answer 6

虽然最好在有错误时让测试失败，但这通常是不切实际的选择。当首次将测试添加到某个区域时，特别容易陷入人们发现的错误中，因此无法完成主要目标。此外，长期失败的测试会变得如此嘈杂，更容易被忽略。

编写失败的测试是修复错误的一部分，并且在修复这些错误很重要时才非常重要。这应该取决于您当前的产品和质量优先级。如果您碰巧将测试作为其他一些努力的副作用，这很好，但不应该让您分散您的实际优先级。

我建议发现任何错误，同时将测试改进警告并提交针对它们的错误。这是一种广度优先的方法，可以帮助您完成当前任务，同时实际使用您学到的内容。然后，当计划修复错误时，可以很容易地将测试变成真正的失败。

与其他受访者不同，我认为失败与警告一样容易被忽视，而培训团队忽略失败的成本太高而无法实现。如果您在此项工作中生成失败测试，​​则在任务改进时，您将破坏回归测试套件的实用程序。

Answer 7

测试失败是一种光环。破解代码与未完成代码之间存在差异，是否应立即解决测试取决于此失败测试所暴露的环境。

如果它坏了，你应该尽快修复它。如果它没有完成，请在有时间时处理它。

在任何一种情况下，很明显你可以忍受它的表现很糟糕（现在），所以只要问题被记录下来，你可能不会在你有时间修复它之前唠叨它。