Question

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

alt text http://i49.tinypic.com/2aeo8kn.png

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

alt text http://i48.tinypic.com/25kj1x2.png

哪个有效，但不如JUnit那么优雅。你知道它是否存在断言宏alàJUnitfor XCode（OCUnit）？此外，是否可以在XCode中获得红色/绿色条？

Answer 1

要注意的第一件事是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()或NSLog()。如果您通过nil，则只会收到默认错误而无需额外详细信息。

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

要回答你的上一个问题，目前还没有办法在Xcode中获得红色/绿色条，就像你在JUnit中看到的那样。这可能是一个很好的补充，但不是我个人认为关键的东西。 YMMV。

Answer 2

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

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

关于红色/绿色条，您会在构建窗口中获得红色/绿色结果作为构建的最后一步，但它不像其他IDE那样可见。有很多好的心理学文献表明，使它更加突出是一个好主意。绝对在bugreport.apple.com提交增强请求。您可以参考rdar://7685315（我的此门票）。

Answer 3

现在有一个很棒的框架叫做OCHamcrest。它允许你的测试断言读起来像一个句子，一般来说你不必提供失败描述，这对我来说是我在测试中要做的最后一件事，因为它必须保持

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

以下是自述文件中的示例

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

断言非常友好，并且添加自己的断言非常简单。

Answer 4

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

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

OCUnit中的简化断言

4 个答案: