iOS unit test: How to set/update/examine firstResponder?

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

Using Xcode 5.1 and XCTestCase, this seems to work okay:

- (void)testFirstResponder
{      
  // Make sure the controller's view has a window
  UIWindow *window = [[UIWindow alloc] init];
  [window addSubview:controller.view];

  // Call whatever method you're testing
  [controller.textView becomeFirstResponder];

  // Assert that the desired subview is the first responder
  XCTAssertTrue([sut.textView isFirstResponder]);
}

In order for a view/subview to become first responder, it must be part of a view hierarchy, meaning that its root view's window property must be set.

Jon and Sergio mention that you may need to call [[NSRunLoop currentRunLoop] runUntilDate:[NSDate date]] after calling becomeFirstResponderon your desired subview, but I found that this wasn't required in our instance.

However, your mileage may vary (even depending on the version of Xcode you're using), so you may or may not need to include such call.

Answer 2

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: