现在，我们触发 view 加载，并且模拟一行被点击：
UIView *view = photosViewController.view; STAssertNotNil(view, @""); NSIndexPath* indexPath = [NSIndexPath indexPathForRow:0 inSection:0]; [photosViewController tableView:photosViewController.tableView didSelectRowAtIndexPath:indexPath];
最后我们验证 mocks 上期望的方法被调用过：
[mockNavController verify]; [photosViewControllerMock verify];
现在我们有了一个测试，用来测试和 navigation controller 的交互，以及正确 view controller 的创建。
又一次地，我们在示例程序中使用了便捷的方法：
- (id)autoVerifiedMockForClass:(Class)aClass; - (id)autoVerifiedPartialMockForObject:(id)object;
于是，我们不需要记住调用 -verify。
进一步探索
就像你从上面看到的那样，partial mocking 非常强大。如果你看看 -[PhotosViewController setupTableView] 方法的源码，你就会看到它是如何从 app delegate 中取出 model 对象的。
NSArray *photos = [AppDelegate sharedDelegate].store.sortedPhotos;
上面的测试依赖于这行代码。打破这种依赖的一种方式是再次使用 partial mocking，让 app delegate 返回预定义的数据，就像这样：
id storeMock; // assume we've set this up id appDelegate = [AppDelegate sharedDelegate] id appDelegateMock = [OCMockObject partialMockForObject:appDelegate]; [[[appDelegateMock stub] andReturn:storeMock] store];
现在，无论 [AppDelegate sharedDelegate].store 时候调用过，它也会返回 storeMock。可以把它发挥到极致。确保让你的测试尽可能保持简单，除非确实有复杂的需要。
牢记的事
Partial mocks 会修改 mocking 的对象，并且在 mocks 的生存期一直有效。你可以通过提前调用 [aMock stopMocking] 来停止这种行为。大多数时候，你希望 partial mock 在整个测试期间都保持有效。确保在测试方法最后放置 [aMock verify]。否则 ARC 会过早 dealloc 这个 mock。而且不管怎样，你都希望加上 -verify。
测试 NIB 加载
PhotoCell 设置在一个 NIB 中，我们可以写一个简单的测试来检查 outlets 设置得是否正确。我们来回顾一下 PhotoCell 类：
@interface PhotoCell : UITableViewCell + (UINib *)nib; @property (weak, nonatomic) IBOutlet UILabel* photoTitleLabel; @property (weak, nonatomic) IBOutlet UILabel* photoDateLabel; @end
我们的简单测试的实现看上去是这样：
| @implementation PhotoCellTests - (void)testNibLoading; { UINib *nib = [PhotoCell nib]; STAssertNotNil(nib, @""); NSArray *a = [nib instantiateWithOwner:nil options:@{}]; STAssertEquals([a count], (NSUInteger) 1, @""); PhotoCell *cell = a[0]; STAssertTrue([cell isMemberOfClass:[PhotoCell class]], @""); // Check that outlets are set up correctly: STAssertNotNil(cell.photoTitleLabel, @""); STAssertNotNil(cell.photoDateLabel, @""); } @end |
非常基础，但是它能工作。
值得一提的是，当有什么发生变动时，测试和相应的类或 nib 需要同时更新。这是事实。你需要把它和 outlets 变化的可能性做权衡。如果你用了 .xib 文件，你可能要注意了，这是经常发生的事。
关于 Class 和 Injection
我们已经从与 Xcode 集成得知，测试 bundle 会注入到应用程序中。省略注入的如何工作的细节（它本身是个巨大的话题），简单地说：注入是把待注入的 bundle（我们的测试 bundle）中的 Objective-C 类添加到运行的应用程序中。这很好，因为这样允许我们运行测试了。
还有一件事会很让人迷惑，那就是如果我们同时把一个类添加到应用程序和测试 bundle中。如果在上面的示例程序中，（偶然）把 PhotoCell 类添加到测试 bundle 和应用程序，然后在测试 bundle 中调用 [PhotoCell class] 会返回一个不同的指针（你应用程序中的那个类）。于是我们的测试将会失败：
STAssertTrue([cell isMemberOfClass:[PhotoCell class]], @"");
再一次声明：注入很复杂。你应该避免：不要把应用程序中的 .m 文件添加到测试 target 中。否则你会得到预想不到的行为。
额外的思考
如果你使用一个持续集成的解决方案，让你的测试启动和运行是一个好主意。详细的描述超过了本文的范围。这些脚本通过 RunUnitTests 脚本触发。还有个 TEST_AFTER_BUILD 环境变量。
一个有趣的选择是创建单独的测试 bundle 来自动化性能测试。你可以在测试方法里做任何你想做的。定时调用一些方法并使用 STAssert 来检查它们是否在特定阈值里面是一种选择。
