编写单元测试来验证 NSTimer 是否已启动

Question

我正在使用XCTest 和OCMock 为iOS 应用程序编写单元测试，我需要指导如何最好地设计一个单元测试来验证方法是否导致NSTimer 被启动。

被测代码：

- (void)start {
    ...
    self.timer = [NSTimer timerWithTimeInterval:1.0
                                         target:self
                                       selector:@selector(tick:)
                                       userInfo:nil
                                        repeats:YES];
    NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
    [runLoop addTimer:self.timer forMode:NSDefaultRunLoopMode];
    ...
}

我要测试的是计时器是用正确的参数创建的，并且计时器被安排在运行循环上运行。

我想到了以下我不满意的选项：

1. 实际上等待计时器触发。 （我不喜欢它的原因：糟糕的单元测试实践。它更像是一个缓慢的集成测试。）
2. 将计时器启动代码提取到私有方法中，在类扩展文件中将该私有方法公开给单元测试，并使用模拟期望来验证私有方法是否被调用。 （我不喜欢它的原因：它验证方法是否被调用，但不是该方法实际设置计时器以正确运行。另外，公开私有方法不是一个好习惯。）
3. 为被测代码提供一个模拟NSTimer。 （我不喜欢它的原因：无法验证它是否真的被安排运行，因为计时器是通过运行循环而不是从某些NSTimer start 方法启动的。）
4. 提供一个模拟 NSRunLoop 并验证 addTimer:forMode: 是否被调用。 （我不喜欢它的原因：我必须在运行循环中提供一个接口？这看起来很古怪。）

有人可以提供一些单元测试指导吗？

Answer 1

好的！花了一段时间才弄清楚如何做到这一点。我将完整地解释我的思考过程。抱歉啰嗦了。

首先，我必须弄清楚我在测试什么。我的代码做了两件事：它启动一个重复计时器，然后计时器有一个回调，让我的代码做其他事情。这是两个独立的行为，这意味着两个不同的单元测试。

那么如何编写单元测试来验证您的代码是否正确启动了重复计时器？您可以在单元测试中测试三件事：

• 方法的返回值
• 系统状态或行为的更改（最好通过公共接口提供）
• 您的代码与您无法控制的其他代码的交互

对于NSTimer 和NSRunLoop，我必须测试交互，因为无法从外部验证计时器是否配置正确。说真的，没有repeats 属性。您必须拦截创建计时器本身的方法调用。

接下来，我意识到如果我使用+scheduledTimerWithTimeInterval:target:selector:userInfo:repeats 创建计时器，我根本不必触摸NSRunLoop，它会自动启动计时器。我需要测试的互动少了一次。

最后，要创建调用 +scheduledTimerWithTimeInterval:target:selector:userInfo:repeats 的期望，您必须模拟 NSTimer 类，幸好 OCMock 现在可以做到。下面是测试的样子：

id mockTimer = [OCMockObject mockForClass:[NSTimer class]];
[[mockTimer expect] scheduledTimerWithTimeInterval:1.0
                                            target:[OCMArg any]
                                          selector:[OCMArg anySelector]
                                          userInfo:[OCMArg any]
                                           repeats:YES];

<your code that should create/schedule NSTimer>

[mockTimer verify];

看着这个测试，我想，“等等，你怎么能真正测试定时器配置了正确的目标和选择器？”好吧，我终于意识到我实际上不应该关心它是否配置了特定的目标和选择器，我应该只关心当计时器触发时，它会做我需要它做的事情。这对于编写好的、面向未来的单元测试来说是非常重要的一点：真的尽量不要依赖私有接口或实现细节，因为这些事情会发生变化。相反，测试您的代码不会改变的行为，并通过公共接口进行。

这将我们带到第二个单元测试：计时器是否完成了我需要它做的事情？为了测试这一点，幸好NSTimer 有-fire，这会导致计时器在目标上执行选择器。因此，您甚至不需要创建一个假的 NSTimer，或者执行提取和覆盖来创建自定义模拟计时器，您所要做的就是让它撕裂：

id mockObserver = [OCMockObject observerMock];
[[NSNotificationCenter defaultCenter] addMockObserver:mockObserver
                                                 name:@"SomeNotificationName"
                                               object:nil];
[[mockObserver expect] notificationWithName:@"SomeNotificationName"
                                     object:[OCMArg any]];
[myCode startTimer];

[myCode.timer fire];

[mockObserver verify];
[[NSNotificationCenter defaultCenter] removeObserver:mockObserver];

关于本次测试的几点意见：

• 当计时器触发时，测试期望将NSNotification 发布到默认NSNotificationCenter。 OCMock 没有让您失望：通知广播测试就是这么简单。
• 要真正触发计时器触发，您需要对计时器的引用。我的测试类没有在公共接口中公开 NSTimer，所以我这样做的方法是创建一个类扩展，将私有 NSTimer 属性公开给我的测试，as described in this SO post。

Answer 2

我真的很喜欢 Richard 的第一种方法，我稍微扩展了代码以使用块调用以避免引用私有 NSTimer 属性。

[[mockAPIClient expect] someMethodSuccess:[OCMIsNotNilConstraint constraint]
                                  failure:[OCMIsNotNilConstraint constraint];

id mockTimer = [OCMockObject mockForClass:[NSTimer class]];
[[[mockTimer expect] andDo:^(NSInvocation *invocation) {
    SEL selector = nil;
    [invocation getArgument:&selector atIndex:4];
    [testSubject performSelector:selector];
}] scheduledTimerWithTimeInterval:10.0
                           target:testSubject
                         selector:[OCMArg anySelector]
                         userInfo:nil
                          repeats:YES];

[testSubject viewWillAppear:YES];

[mockTimer verify];
[mockAPIClient verify];