我应该对已知缺陷进行单元测试吗？

如果我的代码包含一个应该修复的已知缺陷，但尚未修复，并且不会在当前版本中修复，并且在可预见的将来可能不会修复，如果该缺陷中的某个单元测试失败，测试套件？如果添加单元测试，它将（显然）会失败，并且习惯于失败的测试似乎是个坏主意。另一方面，如果它是一个已知的缺陷，并且存在一个已知的失败案例，那么将其排除在测试套件之外似乎很奇怪，因为应该在某个时间点对其进行修复，并且该测试已经可以使用。

答案是肯定的，您应该编写它们并运行它们。

您的测试框架需要“已知失败的测试”类别，您应该将这些测试标记为属于该类别。您如何执行此操作取决于框架。

奇怪的是，突然通过的失败测试与意外失败的通过测试一样有趣。

我认为您应该针对当前行为进行单元测试，并在注释中添加正确的测试和正确的行为。例：

@Test
public void test() {
  // this is wrong, it should be fixed some time
  Assert.assertEquals(2, new Calculator().plus(2,2));
  // this is the expected behaviour, replace the above test when the fix is available
  // Assert.assertEquals(4, new Calculator().plus(2, 2));
}

这样，当修复程序可用时，构建将失败，并通知您测试失败。当您查看测试时，您将知道您已更改了行为并且必须更新测试。

编辑：正如曼上尉所说，在大型项目中，这不会很快得到解决，但是出于文档的考虑，原始答案总比没有好。

更好的方法是复制当前测试，使克隆断言正确的事情，@Ignore并用一条消息声明它，例如

@Test
public void test() {
  Assert.assertEquals(2, new Calculator().plus(2,2));
}

@Ignore("fix me, Calculator is giving the wrong result, see ticket BUG-12345 and delete #test() when fixed")
@Test
public void fixMe() {
  Assert.assertEquals(4, new Calculator().plus(2, 2));
}

这与您团队中的约定减少了@Ignored个测试的次数。与引入或更改测试以反映错误的方式相同，不同之处在于，如果这对您的团队至关重要，则不会使构建失败，例如OP表示该错误修复将不包含在当前版本中。

根据测试工具的不同，您可以使用omit或pend功能。

红宝石示例：

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test 


class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

该omit命令跳过测试，omit_if将其与测试结合-在我的示例中，我测试版本号，并且仅对希望解决错误的版本执行测试。

我的示例的输出是：

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================


Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

所以我的答案是：实施测试。但是不要将测试人员与错误混为一谈，因为它会导致测试失败。

如果您很快就发现了该错误，并且您有时间现在编写单元测试，那么我现在就编写它并将其标记为已知失败，这样它就不会使构建本身失败。您的错误跟踪器应进行更新，以反映当前有一个单元测试无法解决此错误，以便最终负责修复该问题的人员不会再次编写该错误。假设错误的代码不需要大量的重构，并且API发生了很大的变化-如果是这种情况，那么您最好不要编写单元测试，除非您对测试的编写方式有了更好的了解。

答案是恕我直言。在开始修复该错误之前，您不应该为该错误添加单元测试，然后您将根据该错误报告编写证明该错误的测试以及该测试失败的时间（ s）您将去更正实际代码以使测试通过，并且错误将得到解决，然后将其覆盖。

在我的世界中，我们将有一个手动测试用例，即在修复错误之前，QE均将失败。作为开发人员，我们将通过手动失败的TC和错误跟踪器意识到这一点。

不添加失败的UT的原因很简单。UT用于直接反馈和验证我作为开发人员目前正在从事的工作。在CI系统中使用了UT，以确保我没有在该模块的其他代码区域中无意间破坏了某些内容。让UT故意由于已知错误而失败，恕我直言，这会适得其反，而且纯属错误。

我想答案确实是，这取决于。务实一些。现在编写它有什么好处？也许这是新鲜的想法？

修复错误时，通过编写暴露该错误的单元测试来证明它的存在是很有意义的。然后，您修复了该错误，单元测试应该通过了。

您现在是否有时间编写失败的单元测试？是否还有更多急需的功能或错误需要编写/修复。

假设您已经具有功能强大的错误跟踪软件并记录了错误，那么实际上现在就无需编写失败的单元测试了。

如果在没有漏洞修复的情况下发布发布之前引入失败的单元测试，则可能会引起一些困惑。

对于测试套件中的已知故障，我通常会感到不安，因为随着时间的推移，列表很容易增长，或者同一测试中不相关的故障很容易被视为“预期”，因此我很不高兴。间歇性故障也是如此-代码中可能隐藏着一些邪恶的东西。我投票支持现在就为代码编写测试，并且应该在修复后以某种方式注释掉或禁用它。