Question

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

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

使用REVISIT或TODO评论注释失败的测试用例。
- 优势：我们将始终知道何时引入新缺陷，而不是我们已经知道的缺陷。
- 缺点：可能忘记重新审核已注释掉的测试用例，这意味着缺陷可能会漏掉。
让测试用例失败。
- 优势：不会忘记修复缺陷，因为脚本失败会不断提醒您存在缺陷。
- 缺点：由于故障噪音而导致新缺陷出现时很难检测到。

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

通过的百分比：75％
百分比失败（预期）：20％
百分比失败（意外）：5％

您基本上会使用某些元数据标记您期望的任何测试用例（由于某些缺陷）。这可以确保您在测试结束时仍然可以看到失败结果，但会立即知道是否存在您不期望的新失败。这似乎是上述两项提案中最好的部分。

有没有人有任何管理此方法的最佳做法？

Answer 1

我会留下您的测试用例。根据我的经验，使用类似

的方式注释代码

// TODO:  fix test case

类似于：

// HAHA: you'll never revisit me

严肃地说，随着您越来越接近发布，在代码中重新访问TODO的愿望趋于消退，特别是对于单元测试这样的事情，因为您专注于修复代码的其他部分。

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

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

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

Answer 2

立即修复错误。

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

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

Answer 3

我通常使用Perl和Perl的Test :: *模块允许您插入TODO块：

TODO: {
  local $TODO = "This has not been implemented yet."

  # Tests expected to fail go here
}

在测试运行的详细输出中，$ TODO中的消息被附加到TODO块中每个测试的通过/失败报告中，以便解释预期失败的原因。对于测试结果的摘要，所有TODO测试都被视为成功，但是，如果任何实际返回成功的结果，摘要也将计算这些并报告意外成功的测试数。

那么，我的建议是找到一个具有类似功能的测试工具。（或者只是使用Perl进行测试，即使正在测试的代码是另一种语言......）

Answer 4

我倾向于将这些留在Ignore属性中（这是使用NUnit） - 测试在测试运行输出中提到，所以它是可见的，希望我们不会忘记它。请考虑在“忽略”消息中添加问题/故障单ID。这样，当底层问题被认为是成熟时，它将得到解决 - 立即修复失败的测试会很好，但有时小错误必须等到时机成熟。

我已经考虑了Explicit属性，它具有无需重新编译即可运行的优点，但它不需要“reason”参数，并且在我们运行的NUnit版本中，测试不会在输出中显示为unrun。

Answer 5

我们做了以下事情：在测试中设置层次结构。

示例：您必须测试3件事。

测试登录（登录，检索用户名，获取“上次登录日期”或熟悉的东西等）。
测试数据库检索（搜索给定的“schnitzelmitkartoffelsalat” - 标记，搜索最新标记）
测试Web服务（连接，获取版本号，检索简单数据，检索详细数据，更改数据）

每个测试点都有子点，如括号中所述。我们分裂这些等级。以最后一个例子为例：

3. Connect to a web service
    ...
3.1. Get the version number
    ...
3.2. Data:
    3.2.1. Get the version number
    3.2.2. Retrieve simple data
    3.2.3. Retrieve detailed data
    3.2.4. Change data

如果某个点失败（开发时）会给出一条确切的错误消息。即3.2.2。失败。然后测试单元不会执行3.2.3的测试。和3.2.4。。这样您就会收到一条（确切的）错误消息：“3.2.2 failed”。因此让程序员解决这个问题（第一个）而不是处理3.2.3。和3.2.4。因为这不会有效。

这有助于澄清问题并弄清楚最初需要做些什么。

Answer 6

我认为你需要一个TODO观察者从代码库中产生“TODO”评论。 TODO 是您的测试元数据。它是已知失败消息前面的一行，非常容易关联。

TODO很好。使用它们。通过实际将它们定期存入待办事项来积极管理它们。

Answer 7

在编写新代码之前，Joel "12 Steps to Better Code"上的＃5正在修复错误：

如果你的代码中有一个错误，当你第一次尝试运行它时，你就可以立即修复它，因为所有的代码在你的脑海里仍然很新鲜。

如果您在几天前发现的某些代码中发现了一个错误，它会花费您一段时间来搜索它，但是当您重读您编写的代码时，您会记住所有内容并且您将能够在合理的时间内修复错误。

但是如果你在几个月前发现的代码中发现了一个错误，那么你可能已经忘记了很多关于该代码的内容，而且修复起来要困难得多。到那时你可能正在修复别人的代码，他们可能在度假时在阿鲁巴，在这种情况下，修复错误就像科学：你必须缓慢，有条不紊，细致，你不能确定如何很长一段时间才能发现治愈方法。

如果您发现已经发布的代码中存在错误，那么您将需要付出难以置信的费用才能修复它。

但是如果你真的想忽略失败的测试，请在你使用的任何测试框架中使用[Ignore]属性或其等价物。在MbUnit的HTML输出中，与失败测试的红色相比，忽略的测试以黄色显示。这使您可以轻松地注意到新的测试失败，但您不会忘记已知失败的测试。

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

7 个答案: