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.

Solution 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:

Solution 2

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.

Solution 3

You need to ensure the textField is installed in the view hierarchy.

If the view’s window property holds a UIWindow object, it has been installed in a view hierarchy; if it returns nil, the view is detached from any hierarchy.

Hopefully this helps....

Comments

[Jon Reid]

Good thought, but for unit testing, putting a message on the event queue doesn't work because the test concludes and the fixture is torn down before the assertion. Counterexample: changing STAssertTrue to STAssertFalse makes no difference.

[Jon Reid]

You're right, the UIWindow was nil. Is there a way to change this in a unit test? Pushing the view controller doesn't work because it schedules things, but (as noted in my response to @sergio) not soon enough for a unit test.

[sergio]

Right, this will not work... as a further hint, I have just found out that you could run for some time the run loop before testing the condition: [[NSRunLoop currentRunLoop] runUntilDate:fiveSecondsFromNow]; (from: stackoverflow.com/questions/1077737/…). I am not entirely sure that this solution is really "elegant", but it should work and may be suitable for "smaller" cases (when you do not really need to go with Frank)...

[Jon Reid]

Excellent! Even specifying a run time of zero does the trick.

[Jon Reid]

I now have my answer. +1 for filling in part of the puzzle.

[Jonathan Beebe]

Do you find this works without making the window the key window?

[Xavier Lowmiller]

As of iOS 10.3, this works without making it the key window.