您如何处理预期在开发过程中失败的单元/回归测试？

在软件开发过程中,代码库中可能存在已知问题的错误.如果测试编写良好,这些错误将导致回归/单元测试失败.

我们的团队一直在争论如何管理失败的测试:

使用REVISIT或TODO注释评论失败的测试用例.

优势:我们将始终知道何时引入了新缺陷,而不是我们已经知道的缺陷.

缺点:可能忘记重新评估已注释掉的测试用例,这意味着缺陷可能会漏掉.

让测试用例失败.

优点:不会忘记修复缺陷,因为脚本失败会不断提醒您存在缺陷.

缺点:由于故障噪声,很难检测何时引入新缺陷.

我想探讨一下这方面的最佳实践.就个人而言,我认为三态解决方案最适合确定脚本是否正在通过.例如,当您运行脚本时,您可以看到以下内容:

通过率:75%

失败百分比(预期):20%

失败百分比(意外):5%

您基本上可以使用某些元数据标记您希望失败的测试用例(由于某些缺陷).这可以确保您在测试结束时仍然可以看到失败结果,但会立即知道是否有新的结果您不期望故障.这似乎采取了上述两个提案中最好的部分.

有没有人有任何最佳实践来管理这个？

我会留下您的测试用例.根据我的经验,用类似的东西评论代码

// TODO:  fix test case

类似于做:

// HAHA: you'll never revisit me

严肃地说,随着您越来越接近运输,重新访问TODO代码的愿望趋于消退,尤其是单元测试之类的事情,因为您专注于修复代码的其他部分.

将测试留在您的"三态"解决方案中.但是,我强烈建议尽快修复这些案件.我不断提醒的问题是,在人们看到它们之后,他们往往会掩盖它们并说"哦,是的,我们总是得到那些错误......"

举个例子 - 在我们的一些代码中,我们引入了"可跳过断言"的概念 - 断言可以让你知道存在问题,但允许我们的测试人员将它们移到其他部分.码.我们已经发现QA开始说"哦,是的,我们一直得到断言,我们被告知它是可跳过的"并且没有报告错误.

我想我的建议是,还有另一种选择,即修复测试用例立即发现的错误.可能有不这样做的实际原因,但从长远来看,现在养成这种习惯可能更有益.

立即修复错误.

如果它太复杂而无法立即进行,那么单元测试的单位可能太大了.

丢失单元测试,并将缺陷放入bug数据库中.这样它具有可见性,可以优先考虑等.