3

我刚开始使用 OCUnit，发现断言有点麻烦。在 JUnit 中，我可以编写一个测试来比较如下数字。这个测试显然会失败，但这显示了我可以为两个数字编写的漂亮、简单的断言以及我得到的反馈：“预期 <2> 但是 <3>”，代码很少。

替代文字

到目前为止，我在 XCode 中尝试的是：

替代文字

哪个有效，但不如 JUnit 优雅。你知道它是否存在断言宏 alà JUnit for XCode (OCUnit)？另外，是否可以在 XCode 中获得红/绿条？

4

4 回答 4

6

首先要注意的是 OCUnit（又名 SenTestingKit.framework）与 Xcode 集成，但并不是真正的 Xcode 的一部分。OCUnit 最初是第三方代码，后来成为 Objective-C 单元测试的事实标准，因此 Apple 采用了它并现在对其进行维护。

更重要的是，您看到的输出似乎有些奇怪。我正在使用 Snow Leopard 附带的 Xcode 3.2.1。我尝试了以下测试：

- (void) testNumbers {
    int number1 = 2;
    int number2 = 3;
    STAssertEquals(number1, number2, nil);
    STAssertEquals(4, 5, nil);
}

这是我在 Xcode 构建结果窗格/窗口中看到的错误：

-[ExampleTest testNumbers] : '2' should be equal to '3'
-[ExampleTest testNumbers] : '4' should be equal to '5'

当我双击构建日志中的错误时，Xcode 直接跳转到失败断言的行。

OCUnit 宏当然并不完美，但您在上面使用的示例非常冗长。宏需要 2+ 或 3+ 参数。（STFail例外，只需要 1+ 个参数。）最后一个必需的参数始终是描述的可选格式字符串，并且任何其他参数都用于替换这些占位符，就像您使用printf()or一样NSLog()。如果你通过nil了，你只会得到默认错误而没有额外的细节。

我通常只在测试确实需要上下文时添加描述。例如，断言的测试和/或主题实际上意味着什么。通常情况下，我只是将这些信息作为对断言的评论。越简单越好。:-)

要回答您的最后一个问题，目前没有办法在 Xcode 中像您在 JUnit 中看到的那样获得红/绿条。这可能是一个不错的补充，但我个人认为这不是关键。YMMV。

于 2010-02-24T00:31:34.870 回答
1

正如其他人所说，您可以通过nil作为最后一个参数传递来使宏更容易接受。如果测试失败，这将为您提供默认输出。当然，您可以根据需要提供自己的字符串。BOOL我经常发现这对于具有返回 a或 anid但NSError*通过引用获取的方法的代码很有用，如下所示：

- (void)testFoo {
  NSError *err;
  STAssertTrue([bar fooMethodReturningBOOLError:&err], @"Error: %@ (%@)", err, [err userInfo]);
}

关于红/绿条，在构建窗口中构建的最后一步确实会得到红/绿结果，但它不像在其他 IDE 中那样可见。有很多很好的心理学文献表明，让它更加突出将是一个好主意。一定要在bugreport.apple.com提交增强请求。你可以参考rdar://7685315（我的票有这个效果）。

于 2010-02-24T18:42:02.273 回答
0

现在有一个很棒的框架，叫做 OCHamcrest。它允许您的测试断言读起来像一个句子，而且通常您不必提供失败描述，对我来说，这是我在测试中不想做的最后一件事，因为它必须维护。

这是github https://github.com/hamcrest/OCHamcrest

这是自述文件中的示例

NSCalendarDate* date = [NSCalendarDate dateWithString:@"26 Apr 2008" calendarFormat:@"%d %b %Y"];
assertThat(date, is(onASaturday()))

断言对 OCUnit 非常友好，添加您自己的断言非常简单。

于 2013-01-28T01:31:16.213 回答
-1

为什么不为此创建自己的包装器？

OCUnit 将运行结果转储到控制台窗口，没有 GUI 集成，抱歉。我觉得这很方便，但我已经习惯了。

于 2010-02-11T20:28:29.100 回答