如何编写预期的失败？

Posted 2023-02-24

【中文标题】如何编写预期的失败？

【英文标题】：how to write expected failures?

【发布时间】：2012-12-06 10:42:51

【问题描述】：

在 Xcode 中，在我的单元测试结束时，我得到如下结果：

测试套件“所有测试”于 2012-12-06 10:23:38 +0000 完成

在 4.314 (4.485) 秒内执行了 195 次测试，0 次失败（0 次意外）

我很想知道如何定义预期失败的测试。

通常对于其他测试框架，我喜欢能够将不完整的单元测试定义为提醒未来必须完成的工作。这些测试应仅记录为警告，但如果其他一切正常，仍会产生“成功”的最终结果

看看 Xcode 的输出，我认为有一种方法可以达到同样的效果。但是，我在找到正确的宏来标记不完整/TODO 测试时遇到问题。此外，在我看来，正常故障报告为：

在 2.314 (2.334) 秒内执行了 95 次测试，其中 1 次失败（0 次意外）

因此，任何测试断言失败似乎都是意料之中的。在那种情况下，我什至对（0 个意外）失败的含义感到困惑。

谁能解释那部分日志结果的含义？，如何使用？如何标记未完成的测试？

【参考方案1】：

“意外失败”是抛出且未处理的异常。与通过断言检查的可能预期的失败相反。

OCUnit 不提供将测试标记为“不运行”的方法。要么将它们注释掉（这会使测试不再编译的风险），要么更改方法名称，使其没有“测试”前缀。例如，将 testSomething 重命名为 XXXtestSomething。 （这会留下您忘记将其更改回来的风险。）

【讨论】：

谢谢！再一次，你是伟大的可可测试英雄。在使用 rspec + cucumber 冒险在 Ruby 中完成 100% BDD 之后，我的问题出现了。现在，我了解了 Cocoa 项目中关于 TDD 领域的所有抱怨。

如果这被记录在某处会很高兴。但是 Apple 的单元测试还有很多不足之处。

【参考方案2】：

我的问题的一个解决方案是使用警告预处理器宏来标记必须完成的单元测试。这样，在编译单元测试之后，我就可以很好地了解未来必须完成的工作。这显示在警告面板中，因此它比仅使用 TODO cmets 更具吸引力。

但是，我希望对不完整的测试进行总计数，并找出我的日志报告中始终为“0 意外”计数的含义。