在软件开发过程中,代码库中可能存在已知问题的错误.如果测试编写得很好,这些错误将导致回归/单元测试失败. 我们的团队一直在争论如何管理失败的测试： 使用REVISIT或TODO评论评论失
我们的团队一直在争论如何管理失败的测试：
>使用REVISIT或TODO评论评论失败的测试用例.
>优势：我们将始终知道何时引入了新缺陷,而不是我们已经知道的缺陷.
>缺点：可能忘记重新评估已注释掉的测试用例,这意味着缺陷可能会漏掉.
>让测试用例失败.
>优势：不会忘记修复缺陷,因为脚本失败会不断提醒您存在缺陷.
>缺点：由于故障噪声,很难检测到何时引入新缺陷.
我想探讨一下这方面的最佳实践.就个人而言,我认为三态解决方案最适合确定脚本是否通过.例如,当您运行脚本时,您可以看到以下内容：
>百分比通过率：75％
>百分比失败(预期)：20％
>百分比失败(意外)：5％
您基本上会使用某些元数据标记您希望失败的测试用例(由于某些缺陷).这可以确保您在测试结束时仍然可以看到失败结果,但是立即知道是否存在您不期望的新故障.这似乎采取了上述两个提案中最好的部分.
有没有人有任何最佳实践来管理这个？
我会留下您的测试用例.根据我的经验,用类似的东西评论代码// TODO: fix test case
类似于做：
// HAHA: you'll never revisit me
严肃地说,随着您越来越接近运输,在代码中重新访问TODO的愿望往往会消失,特别是对于单元测试这样的事情,因为您专注于修复代码的其他部分.
将测试留在您的“三态”解决方案中.但是,我强烈建议尽快修复这些案件.我不断提醒的问题是,在人们看到它们之后,他们倾向于掩饰它们并说“哦,是的,我们总是得到那些错误……”
举个例子 – 在我们的一些代码中,我们引入了“可跳过的断言”的概念 – 断言可以让你知道存在问题,但允许我们的测试人员将它们移到其他部分.码.我们已经发现QA开始说“哦,是的,我们一直得到断言,我们被告知它可以跳过”,并且没有报告错误.
我想我的建议是,还有另一种选择,即修复测试用例立即发现的错误.可能有不这样做的实际原因,但从长远来看,现在养成这种习惯可能更有益.