Question

How do you write first responder unit tests?

I’m trying to write a test to confirm that a method advances focus to the next text field. controller is a descendant of UIViewController. But this exploratory test fails:

- (void)testFirstResponder
{
    [controller view];
    [[controller firstTextField] becomeFirstResponder];

    STAssertTrue([[controller firstTextField] isFirstResponder], nil);
}

The first line causes the view to be loaded so that its outlets are in place. The text fields are non-nil. But the test never passes.

I’m guessing that becomeFirstResponder doesn’t set the first responder right away, but schedules it for later. So is there a good way to write a unit test against it?

Pulling up answer from comment in accepted answer… Let things run for a short time:

[[NSRunLoop currentRunLoop] runUntilDate:[NSDate date]];

I’ve also found I need to create a UIWindow and drop the view controller’s view into it, as stated in the most-upvoted answer.

Answer 1

I guess that managing/changing the first responder chain is somehow accomplished in the main loop, when the UI is updated preparing for the next event handling. If this hypothesis is correct, I would simply do the following:

-(void)assertIfNotFirstResponder:(UITextField*)field {
    STAssertTrue([field isFirstResponder], nil);
}

- (void)testFirstResponder
{
     [controller view];
     [[controller firstTextField] becomeFirstResponder];
     [self performSelector:@selector(@"assertIfNotFirstResponder:") withObject:[controller firstTextField] afterDelay:0.0];
 }

Note: I have used a 0.0 delay because I simply want that the message is put on the event queue and dispatched as soon as possible. I need just a way to get back to the main loop, for its housekeeping. This should produce no actual delay in your case. If you are executing several tests of the same kind, i.e. by repeatedly changing the control that is the first responder, this technique should guarantee that all of those events correctly ordered with the ones generated by performSelector.

If you are running your tests from a different thread, you could use – performSelectorOnMainThread:withObject:waitUntilDone: