testing - 我应该继续注册失败吗？

Question

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

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

---

@保罗·汤布林，

明确一点——我从未考虑过删除测试；我只是在考虑修改通过/失败条件以允许失败，而不会在每次运行测试时都出现在我面前。

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

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

Answer 1

如果你停止测试它，你怎么知道它什么时候修复，更重要的是，你怎么知道它是否再次损坏？我反对取消测试，因为您可能会忘记重新添加它。

Answer 2

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

Answer 3

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

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

把它留在里面，更新你的项目笔记，甚至可能降低严重性（如果可能的话），但当然不要破坏正在检查坏事的东西；）

Answer 4

如果它没有做预期的事情，它应该仍然是失败的。

否则，太容易被忽视了。保持简单——它可以工作，也可以不工作。失败或成功:)

——凯文·费尔柴尔德

Answer 5

虽然我同意 Paul 所说的大部分内容，但论点的另一面是回归测试，严格来说，应该测试程序行为的变化，而不仅仅是任何旧错误。他们应该特别告诉你什么时候你破坏了曾经有用的东西。

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

Answer 6

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

编写失败的测试是修复错误的一部分，并且只有在修复这些错误很重要时才真正重要。这应该由您当前的产品和质量优先级决定。如果您碰巧将测试作为其他工作的副作用，那很好，但不应该让您从实际优先事项中分心。

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

与其他受访者不同，我认为失败与警告一样容易被忽略，而且培训团队忽略失败的成本太高，不能让它发生。如果您在此工作中产生了失败的测试，那么当任务改进它时，您将破坏回归测试套件的实用性。

Answer 7

失败的测试是一种光栅。损坏的代码和未完成的代码之间是有区别的，是否应该立即解决测试取决于这个失败的测试暴露的情况。

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

在任何一种情况下，显然你都可以忍受它的不良行为（目前），所以只要记录了问题，你最好不要让它唠叨你，直到你有时间修复它。