unit-testing - 处理可选测试

Question

CATCH 中没有跳过测试的方法, Google Test和其他框架(至少在传统意义上，你指定这样做的原因并在输出中看到它)让我思考我是否需要它(我在过去的项目中一直使用 UnitTest++)。

通常情况下，是的，不应该有任何理由跳过桌面应用程序中的任何内容——您要么测试它，要么不测试它。但就硬件而言 - 有些事情无法保证。

例如，我有两种设备:一种带有嵌入式蜂鸣器，而另一种则没有。在 UnitTest++ 中，我会查询系统，发现蜂鸣器不可用，并且会跳过依赖于它的测试。当然，在 CATCH 中，我可以做类似的事情:在初始化期间查询系统，然后只排除带有标签“beeper”(CATCH 中的 special feature)的所有测试。

但是，有一点不同:测试人员(除我之外的其他人)会读取输出，但找不到提到的那些可选测试(而在 UnitTest++ 中，它们会被标记为已跳过，原因将作为一部分提供的输出)。他的第一个想法:

• 这一定是某个旧版本的测试应用。
• 也许我忘记启用套件 X。
• 可能有什么东西坏了，我应该问问开发商。
• 等等，也许他们只是被跳过了。但为什么？不管怎样，我都会问开发商。

此外，他可能只是没有注意到这些测试被跳过了，而实际上它们可能不应该被跳过(即操作系统返回“false”，无论蜂鸣器是否存在，这是一个主要错误)。一种选择是将“跳过的”测试标记为已通过，但这感觉像是一种不必要的解决方法。

是否有一些我不知道的巧妙技术(即，我不知道，将可选测试完全分离到一个独立的程序中)？如果不是——那我应该坚持使用 UnitTest++ 吗？它完成了工作，但我真的很喜欢 CATCH 的 SECTIONs和 tags , 有助于避免代码重复。

Answer 1

如果您以编程方式检测蜂鸣器的可用性，那么您还可以打印出您正在跳过的测试。

您可以获得与给定测试规范匹配的测试集，如下所示:

  std::vector<TestCase> matchedTestCases;
  getRegistryHub().getTestCaseRegistry().getFilteredTests( testSpec, config, matchedTestCases );

testSpec 是TestSpec 的一个实例。您可以从 config.testSpec() 获取当前版本 - 或者您可以即时创建它(如果您以编程方式过滤测试，则可能需要这样做。这并没有真正记录在那一刻我想回顾整个测试规范并重新设计它。碰巧我上周做了那件事。希望现在这应该相当稳定 - 但我在提交文档之前让它安顿下来。

如果您在代码中搜索“class TestSpec”，您应该能够解决这个问题 - 尽管您可能会发现使用 parseTestSpec() 从字符串中解析它更容易。

您可以使用 getCurrentContext().getConfig() 获取配置对象。