Mixing
UITextFieldDelegate not called in XCTestCase
I'm just starting to get familiar with writing tests using XCTestCase and am exploring its capabilities. I have a simple (if contrived) app that loads a screen with a button and a textfield. When the textfield is selected the view controller populates the textfield:
public func textFieldDidBeginEditing(_ textField: UITextField) {
textField.text = "abcd"
}
I also have functionality that selects the field when the button is pressed:
@IBAction public func selectField(_ sender: Any?) {
print("button press")
textfield.becomeFirstResponder()
}
The code in my test case, programatically taps the button using vc.button.sendActions(for: .touchUpInside)
However, it doesn't appear that the textfield ever becomes first responder and thus the delegate methods are not called. Below is the full test case class:
var vc: ViewController!
override func setUp() {
let sb = UIStoryboard(name: "Main", bundle: nil)
vc = sb.instantiateInitialViewController() as? ViewController
_ = vc.view
}
override func tearDown() {
}
func test_textfieldPopulatesOnSelection() {
vc.button.sendActions(for: .touchUpInside)
let expectation = XCTestExpectation(description: "waiting for textfield to become first responder")
DispatchQueue.main.asyncAfter(deadline: .now() + 5.0) {
print("textfield.text: (self.vc.textfield.text ?? "")")
expectation.fulfill()
}
wait(for: [expectation], timeout: 13.0)
}
While I realize that I'm probably conflating the concepts of UI testing and unit testing, I'm still curious why my delegate methods are not being called.
swift cocoa-touch xctest xctestcase
asked Nov 19 '18 at 17:57
toddgtoddg
2,3052926
add a comment |
I'm just starting to get familiar with writing tests using XCTestCase and am exploring its capabilities. I have a simple (if contrived) app that loads a screen with a button and a textfield. When the textfield is selected the view controller populates the textfield:
public func textFieldDidBeginEditing(_ textField: UITextField) {
textField.text = "abcd"
}
I also have functionality that selects the field when the button is pressed:
@IBAction public func selectField(_ sender: Any?) {
print("button press")
textfield.becomeFirstResponder()
}
The code in my test case, programatically taps the button using vc.button.sendActions(for: .touchUpInside)
However, it doesn't appear that the textfield ever becomes first responder and thus the delegate methods are not called. Below is the full test case class:
var vc: ViewController!
override func setUp() {
let sb = UIStoryboard(name: "Main", bundle: nil)
vc = sb.instantiateInitialViewController() as? ViewController
_ = vc.view
}
override func tearDown() {
}
func test_textfieldPopulatesOnSelection() {
vc.button.sendActions(for: .touchUpInside)
let expectation = XCTestExpectation(description: "waiting for textfield to become first responder")
DispatchQueue.main.asyncAfter(deadline: .now() + 5.0) {
print("textfield.text: (self.vc.textfield.text ?? "")")
expectation.fulfill()
}
wait(for: [expectation], timeout: 13.0)
}
While I realize that I'm probably conflating the concepts of UI testing and unit testing, I'm still curious why my delegate methods are not being called.
swift cocoa-touch xctest xctestcase
asked Nov 19 '18 at 17:57
toddgtoddg
2,3052926
add a comment |
I'm just starting to get familiar with writing tests using XCTestCase and am exploring its capabilities. I have a simple (if contrived) app that loads a screen with a button and a textfield. When the textfield is selected the view controller populates the textfield:
public func textFieldDidBeginEditing(_ textField: UITextField) {
textField.text = "abcd"
}
I also have functionality that selects the field when the button is pressed:
@IBAction public func selectField(_ sender: Any?) {
print("button press")
textfield.becomeFirstResponder()
}
The code in my test case, programatically taps the button using vc.button.sendActions(for: .touchUpInside)
However, it doesn't appear that the textfield ever becomes first responder and thus the delegate methods are not called. Below is the full test case class:
var vc: ViewController!
override func setUp() {
let sb = UIStoryboard(name: "Main", bundle: nil)
vc = sb.instantiateInitialViewController() as? ViewController
_ = vc.view
}
override func tearDown() {
}
func test_textfieldPopulatesOnSelection() {
vc.button.sendActions(for: .touchUpInside)
let expectation = XCTestExpectation(description: "waiting for textfield to become first responder")
DispatchQueue.main.asyncAfter(deadline: .now() + 5.0) {
print("textfield.text: (self.vc.textfield.text ?? "")")
expectation.fulfill()
}
wait(for: [expectation], timeout: 13.0)
}
While I realize that I'm probably conflating the concepts of UI testing and unit testing, I'm still curious why my delegate methods are not being called.
swift cocoa-touch xctest xctestcase
asked Nov 19 '18 at 17:57
toddgtoddg
2,3052926
I'm just starting to get familiar with writing tests using XCTestCase and am exploring its capabilities. I have a simple (if contrived) app that loads a screen with a button and a textfield. When the textfield is selected the view controller populates the textfield:
public func textFieldDidBeginEditing(_ textField: UITextField) {
textField.text = "abcd"
}
I also have functionality that selects the field when the button is pressed:
@IBAction public func selectField(_ sender: Any?) {
print("button press")
textfield.becomeFirstResponder()
}
The code in my test case, programatically taps the button using vc.button.sendActions(for: .touchUpInside)
However, it doesn't appear that the textfield ever becomes first responder and thus the delegate methods are not called. Below is the full test case class:
var vc: ViewController!
override func setUp() {
let sb = UIStoryboard(name: "Main", bundle: nil)
vc = sb.instantiateInitialViewController() as? ViewController
_ = vc.view
}
override func tearDown() {
}
func test_textfieldPopulatesOnSelection() {
vc.button.sendActions(for: .touchUpInside)
let expectation = XCTestExpectation(description: "waiting for textfield to become first responder")
DispatchQueue.main.asyncAfter(deadline: .now() + 5.0) {
print("textfield.text: (self.vc.textfield.text ?? "")")
expectation.fulfill()
}
wait(for: [expectation], timeout: 13.0)
}
While I realize that I'm probably conflating the concepts of UI testing and unit testing, I'm still curious why my delegate methods are not being called.
swift cocoa-touch xctest xctestcase
swift cocoa-touch xctest xctestcase
asked Nov 19 '18 at 17:57
toddgtoddg
2,3052926
asked Nov 19 '18 at 17:57
toddgtoddg
2,3052926
asked Nov 19 '18 at 17:57
toddgtoddg
2,3052926
asked Nov 19 '18 at 17:57
toddgtoddg
2,3052926
asked Nov 19 '18 at 17:57
toddgtoddg
2,3052926
2,3052926
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
I have a simple (if contrived) app that loads a screen with a button and a textfield
No, you don't — at least not in any meaningful sense of the notion "loads a screen". You have a view controller and its view, created in setup, but you have not done anything with them. The view controller is not part of the app's view controller hierarchy, and its view is not in the interface, and so the text field that it contains is not in the interface. A text field not in the interface isn't going to do anything. It cannot be first responder, as there is nothing for it to respond to. The first responder is a feature of the app's window, and your text field is not in any window.
In any case, your use of a unit test here is misconceived. It isn't so much that you are conflating unit tests with user interface tests; it's that you're not honing in on what testing is. There is no point testing the concept that saying becomeFirstResponder makes a text field first responder; you know that that is true, so there is nothing to test. Your job in a unit test is to test your app's functionality, not to test the Cocoa framework.
answered Nov 20 '18 at 0:17
mattmatt
324k45523723
That makes sense. So if I want to test that the textfield's text gets set when it is selected, it's enough to call the delegate methodtextFieldDidBeginEditingdirectly? What about if I want to test that the textfield delegate is properly set?
– toddg
Nov 20 '18 at 2:11
Well, testing that the text field delegate is set is easy: just ask the text field what its delegate is. Testing that the text field text gets set just because the text field gets selected does seem just the sort of thing a UI Test would grapple with. It is not the job of a unit test to put the app's interface behavior through its paces.
– matt
Nov 20 '18 at 5:01
This is really helpful, thank you! I think I'm struggling with the fact that many of my controllers are inherently tied to views. I've heard mvvm is a good antidote to this but I'm not ready to take that project on at the moment.
– toddg
Nov 20 '18 at 16:54
For what it's worth, I unit test view controllers. MVVM (and others) can be helpful, but isn't a requirement. With tests in place, one can refactor to whatever style they like.
– Jon Reid
Nov 20 '18 at 18:59
add a comment |
Delegate methods aren't called in unit tests. It's up to the tests to call delegate methods as if they were called by Cocoa Touch.
So to test textFieldDidBeginEditing(_), the unit test needs to call it explicitly.
answered Nov 19 '18 at 23:49
Jon ReidJon Reid
15.9k24878
"Delegate methods aren't called in unit tests" This doesn't seem quite right. The runtime doesn't have a way of magically saying "oh, it's a unit test, I mustn't let the delegate method get called". No magic switch is thrown turning off entire features of Cocoa just because it's a unit test.
– matt
Nov 20 '18 at 4:58
Then I will add, "Not for a view controller created in isolation by a unit test."
– Jon Reid
Nov 20 '18 at 5:04
OK, we're on the same wavelength. But then you and I are just saying the same thing (which is fine): the problem has nothing to do with the fact that this is a unit test but rather (as I say in my answer) that the text field is not in the interface and cannot become first responder. Non-unit test code, too, could create a free-floating view controller whose view isn't part of the interface, and would get the same result.
– matt
Nov 20 '18 at 5:08
There are tricks like "place in a view hierarchy" and "pump the run loop" that work for first responders. Such tricks are unusual, thankfully.
– Jon Reid
Nov 20 '18 at 19:02
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53380233%2fuitextfielddelegate-not-called-in-xctestcase%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I have a simple (if contrived) app that loads a screen with a button and a textfield
No, you don't — at least not in any meaningful sense of the notion "loads a screen". You have a view controller and its view, created in setup, but you have not done anything with them. The view controller is not part of the app's view controller hierarchy, and its view is not in the interface, and so the text field that it contains is not in the interface. A text field not in the interface isn't going to do anything. It cannot be first responder, as there is nothing for it to respond to. The first responder is a feature of the app's window, and your text field is not in any window.
In any case, your use of a unit test here is misconceived. It isn't so much that you are conflating unit tests with user interface tests; it's that you're not honing in on what testing is. There is no point testing the concept that saying becomeFirstResponder makes a text field first responder; you know that that is true, so there is nothing to test. Your job in a unit test is to test your app's functionality, not to test the Cocoa framework.
answered Nov 20 '18 at 0:17
mattmatt
324k45523723
That makes sense. So if I want to test that the textfield's text gets set when it is selected, it's enough to call the delegate methodtextFieldDidBeginEditingdirectly? What about if I want to test that the textfield delegate is properly set?
– toddg
Nov 20 '18 at 2:11
Well, testing that the text field delegate is set is easy: just ask the text field what its delegate is. Testing that the text field text gets set just because the text field gets selected does seem just the sort of thing a UI Test would grapple with. It is not the job of a unit test to put the app's interface behavior through its paces.
– matt
Nov 20 '18 at 5:01
This is really helpful, thank you! I think I'm struggling with the fact that many of my controllers are inherently tied to views. I've heard mvvm is a good antidote to this but I'm not ready to take that project on at the moment.
– toddg
Nov 20 '18 at 16:54
For what it's worth, I unit test view controllers. MVVM (and others) can be helpful, but isn't a requirement. With tests in place, one can refactor to whatever style they like.
– Jon Reid
Nov 20 '18 at 18:59
add a comment |
I have a simple (if contrived) app that loads a screen with a button and a textfield
No, you don't — at least not in any meaningful sense of the notion "loads a screen". You have a view controller and its view, created in setup, but you have not done anything with them. The view controller is not part of the app's view controller hierarchy, and its view is not in the interface, and so the text field that it contains is not in the interface. A text field not in the interface isn't going to do anything. It cannot be first responder, as there is nothing for it to respond to. The first responder is a feature of the app's window, and your text field is not in any window.
In any case, your use of a unit test here is misconceived. It isn't so much that you are conflating unit tests with user interface tests; it's that you're not honing in on what testing is. There is no point testing the concept that saying becomeFirstResponder makes a text field first responder; you know that that is true, so there is nothing to test. Your job in a unit test is to test your app's functionality, not to test the Cocoa framework.
answered Nov 20 '18 at 0:17
mattmatt
324k45523723
That makes sense. So if I want to test that the textfield's text gets set when it is selected, it's enough to call the delegate methodtextFieldDidBeginEditingdirectly? What about if I want to test that the textfield delegate is properly set?
– toddg
Nov 20 '18 at 2:11
Well, testing that the text field delegate is set is easy: just ask the text field what its delegate is. Testing that the text field text gets set just because the text field gets selected does seem just the sort of thing a UI Test would grapple with. It is not the job of a unit test to put the app's interface behavior through its paces.
– matt
Nov 20 '18 at 5:01
This is really helpful, thank you! I think I'm struggling with the fact that many of my controllers are inherently tied to views. I've heard mvvm is a good antidote to this but I'm not ready to take that project on at the moment.
– toddg
Nov 20 '18 at 16:54
For what it's worth, I unit test view controllers. MVVM (and others) can be helpful, but isn't a requirement. With tests in place, one can refactor to whatever style they like.
– Jon Reid
Nov 20 '18 at 18:59
add a comment |
I have a simple (if contrived) app that loads a screen with a button and a textfield
No, you don't — at least not in any meaningful sense of the notion "loads a screen". You have a view controller and its view, created in setup, but you have not done anything with them. The view controller is not part of the app's view controller hierarchy, and its view is not in the interface, and so the text field that it contains is not in the interface. A text field not in the interface isn't going to do anything. It cannot be first responder, as there is nothing for it to respond to. The first responder is a feature of the app's window, and your text field is not in any window.
In any case, your use of a unit test here is misconceived. It isn't so much that you are conflating unit tests with user interface tests; it's that you're not honing in on what testing is. There is no point testing the concept that saying becomeFirstResponder makes a text field first responder; you know that that is true, so there is nothing to test. Your job in a unit test is to test your app's functionality, not to test the Cocoa framework.
answered Nov 20 '18 at 0:17
mattmatt
324k45523723
I have a simple (if contrived) app that loads a screen with a button and a textfield
No, you don't — at least not in any meaningful sense of the notion "loads a screen". You have a view controller and its view, created in setup, but you have not done anything with them. The view controller is not part of the app's view controller hierarchy, and its view is not in the interface, and so the text field that it contains is not in the interface. A text field not in the interface isn't going to do anything. It cannot be first responder, as there is nothing for it to respond to. The first responder is a feature of the app's window, and your text field is not in any window.
In any case, your use of a unit test here is misconceived. It isn't so much that you are conflating unit tests with user interface tests; it's that you're not honing in on what testing is. There is no point testing the concept that saying becomeFirstResponder makes a text field first responder; you know that that is true, so there is nothing to test. Your job in a unit test is to test your app's functionality, not to test the Cocoa framework.
answered Nov 20 '18 at 0:17
mattmatt
324k45523723
edited Nov 20 '18 at 5:09
answered Nov 20 '18 at 0:17
mattmatt
324k45523723
answered Nov 20 '18 at 0:17
mattmatt
324k45523723
answered Nov 20 '18 at 0:17
mattmatt
324k45523723
324k45523723
That makes sense. So if I want to test that the textfield's text gets set when it is selected, it's enough to call the delegate methodtextFieldDidBeginEditingdirectly? What about if I want to test that the textfield delegate is properly set?
– toddg
Nov 20 '18 at 2:11
Well, testing that the text field delegate is set is easy: just ask the text field what its delegate is. Testing that the text field text gets set just because the text field gets selected does seem just the sort of thing a UI Test would grapple with. It is not the job of a unit test to put the app's interface behavior through its paces.
– matt
Nov 20 '18 at 5:01
This is really helpful, thank you! I think I'm struggling with the fact that many of my controllers are inherently tied to views. I've heard mvvm is a good antidote to this but I'm not ready to take that project on at the moment.
– toddg
Nov 20 '18 at 16:54
For what it's worth, I unit test view controllers. MVVM (and others) can be helpful, but isn't a requirement. With tests in place, one can refactor to whatever style they like.
– Jon Reid
Nov 20 '18 at 18:59
add a comment |
That makes sense. So if I want to test that the textfield's text gets set when it is selected, it's enough to call the delegate methodtextFieldDidBeginEditingdirectly? What about if I want to test that the textfield delegate is properly set?
– toddg
Nov 20 '18 at 2:11
Well, testing that the text field delegate is set is easy: just ask the text field what its delegate is. Testing that the text field text gets set just because the text field gets selected does seem just the sort of thing a UI Test would grapple with. It is not the job of a unit test to put the app's interface behavior through its paces.
– matt
Nov 20 '18 at 5:01
This is really helpful, thank you! I think I'm struggling with the fact that many of my controllers are inherently tied to views. I've heard mvvm is a good antidote to this but I'm not ready to take that project on at the moment.
– toddg
Nov 20 '18 at 16:54
For what it's worth, I unit test view controllers. MVVM (and others) can be helpful, but isn't a requirement. With tests in place, one can refactor to whatever style they like.
– Jon Reid
Nov 20 '18 at 18:59
That makes sense. So if I want to test that the textfield's text gets set when it is selected, it's enough to call the delegate method
textFieldDidBeginEditing directly? What about if I want to test that the textfield delegate is properly set?– toddg
Nov 20 '18 at 2:11
That makes sense. So if I want to test that the textfield's text gets set when it is selected, it's enough to call the delegate method
textFieldDidBeginEditing directly? What about if I want to test that the textfield delegate is properly set?– toddg
Nov 20 '18 at 2:11
Well, testing that the text field delegate is set is easy: just ask the text field what its delegate is. Testing that the text field text gets set just because the text field gets selected does seem just the sort of thing a UI Test would grapple with. It is not the job of a unit test to put the app's interface behavior through its paces.
– matt
Nov 20 '18 at 5:01
Well, testing that the text field delegate is set is easy: just ask the text field what its delegate is. Testing that the text field text gets set just because the text field gets selected does seem just the sort of thing a UI Test would grapple with. It is not the job of a unit test to put the app's interface behavior through its paces.
– matt
Nov 20 '18 at 5:01
This is really helpful, thank you! I think I'm struggling with the fact that many of my controllers are inherently tied to views. I've heard mvvm is a good antidote to this but I'm not ready to take that project on at the moment.
– toddg
Nov 20 '18 at 16:54
This is really helpful, thank you! I think I'm struggling with the fact that many of my controllers are inherently tied to views. I've heard mvvm is a good antidote to this but I'm not ready to take that project on at the moment.
– toddg
Nov 20 '18 at 16:54
For what it's worth, I unit test view controllers. MVVM (and others) can be helpful, but isn't a requirement. With tests in place, one can refactor to whatever style they like.
– Jon Reid
Nov 20 '18 at 18:59
For what it's worth, I unit test view controllers. MVVM (and others) can be helpful, but isn't a requirement. With tests in place, one can refactor to whatever style they like.
– Jon Reid
Nov 20 '18 at 18:59
add a comment |
Delegate methods aren't called in unit tests. It's up to the tests to call delegate methods as if they were called by Cocoa Touch.
So to test textFieldDidBeginEditing(_), the unit test needs to call it explicitly.
answered Nov 19 '18 at 23:49
Jon ReidJon Reid
15.9k24878
"Delegate methods aren't called in unit tests" This doesn't seem quite right. The runtime doesn't have a way of magically saying "oh, it's a unit test, I mustn't let the delegate method get called". No magic switch is thrown turning off entire features of Cocoa just because it's a unit test.
– matt
Nov 20 '18 at 4:58
Then I will add, "Not for a view controller created in isolation by a unit test."
– Jon Reid
Nov 20 '18 at 5:04
OK, we're on the same wavelength. But then you and I are just saying the same thing (which is fine): the problem has nothing to do with the fact that this is a unit test but rather (as I say in my answer) that the text field is not in the interface and cannot become first responder. Non-unit test code, too, could create a free-floating view controller whose view isn't part of the interface, and would get the same result.
– matt
Nov 20 '18 at 5:08
There are tricks like "place in a view hierarchy" and "pump the run loop" that work for first responders. Such tricks are unusual, thankfully.
– Jon Reid
Nov 20 '18 at 19:02
add a comment |
Delegate methods aren't called in unit tests. It's up to the tests to call delegate methods as if they were called by Cocoa Touch.
So to test textFieldDidBeginEditing(_), the unit test needs to call it explicitly.
answered Nov 19 '18 at 23:49
Jon ReidJon Reid
15.9k24878
"Delegate methods aren't called in unit tests" This doesn't seem quite right. The runtime doesn't have a way of magically saying "oh, it's a unit test, I mustn't let the delegate method get called". No magic switch is thrown turning off entire features of Cocoa just because it's a unit test.
– matt
Nov 20 '18 at 4:58
Then I will add, "Not for a view controller created in isolation by a unit test."
– Jon Reid
Nov 20 '18 at 5:04
OK, we're on the same wavelength. But then you and I are just saying the same thing (which is fine): the problem has nothing to do with the fact that this is a unit test but rather (as I say in my answer) that the text field is not in the interface and cannot become first responder. Non-unit test code, too, could create a free-floating view controller whose view isn't part of the interface, and would get the same result.
– matt
Nov 20 '18 at 5:08
There are tricks like "place in a view hierarchy" and "pump the run loop" that work for first responders. Such tricks are unusual, thankfully.
– Jon Reid
Nov 20 '18 at 19:02
add a comment |
Delegate methods aren't called in unit tests. It's up to the tests to call delegate methods as if they were called by Cocoa Touch.
So to test textFieldDidBeginEditing(_), the unit test needs to call it explicitly.
answered Nov 19 '18 at 23:49
Jon ReidJon Reid
15.9k24878
Delegate methods aren't called in unit tests. It's up to the tests to call delegate methods as if they were called by Cocoa Touch.
So to test textFieldDidBeginEditing(_), the unit test needs to call it explicitly.
answered Nov 19 '18 at 23:49
Jon ReidJon Reid
15.9k24878
answered Nov 19 '18 at 23:49
Jon ReidJon Reid
15.9k24878
answered Nov 19 '18 at 23:49
Jon ReidJon Reid
15.9k24878
answered Nov 19 '18 at 23:49
Jon ReidJon Reid
15.9k24878
15.9k24878
"Delegate methods aren't called in unit tests" This doesn't seem quite right. The runtime doesn't have a way of magically saying "oh, it's a unit test, I mustn't let the delegate method get called". No magic switch is thrown turning off entire features of Cocoa just because it's a unit test.
– matt
Nov 20 '18 at 4:58
Then I will add, "Not for a view controller created in isolation by a unit test."
– Jon Reid
Nov 20 '18 at 5:04
OK, we're on the same wavelength. But then you and I are just saying the same thing (which is fine): the problem has nothing to do with the fact that this is a unit test but rather (as I say in my answer) that the text field is not in the interface and cannot become first responder. Non-unit test code, too, could create a free-floating view controller whose view isn't part of the interface, and would get the same result.
– matt
Nov 20 '18 at 5:08
There are tricks like "place in a view hierarchy" and "pump the run loop" that work for first responders. Such tricks are unusual, thankfully.
– Jon Reid
Nov 20 '18 at 19:02
add a comment |
"Delegate methods aren't called in unit tests" This doesn't seem quite right. The runtime doesn't have a way of magically saying "oh, it's a unit test, I mustn't let the delegate method get called". No magic switch is thrown turning off entire features of Cocoa just because it's a unit test.
– matt
Nov 20 '18 at 4:58
Then I will add, "Not for a view controller created in isolation by a unit test."
– Jon Reid
Nov 20 '18 at 5:04
OK, we're on the same wavelength. But then you and I are just saying the same thing (which is fine): the problem has nothing to do with the fact that this is a unit test but rather (as I say in my answer) that the text field is not in the interface and cannot become first responder. Non-unit test code, too, could create a free-floating view controller whose view isn't part of the interface, and would get the same result.
– matt
Nov 20 '18 at 5:08
There are tricks like "place in a view hierarchy" and "pump the run loop" that work for first responders. Such tricks are unusual, thankfully.
– Jon Reid
Nov 20 '18 at 19:02
"Delegate methods aren't called in unit tests" This doesn't seem quite right. The runtime doesn't have a way of magically saying "oh, it's a unit test, I mustn't let the delegate method get called". No magic switch is thrown turning off entire features of Cocoa just because it's a unit test.
– matt
Nov 20 '18 at 4:58
"Delegate methods aren't called in unit tests" This doesn't seem quite right. The runtime doesn't have a way of magically saying "oh, it's a unit test, I mustn't let the delegate method get called". No magic switch is thrown turning off entire features of Cocoa just because it's a unit test.
– matt
Nov 20 '18 at 4:58
Then I will add, "Not for a view controller created in isolation by a unit test."
– Jon Reid
Nov 20 '18 at 5:04
Then I will add, "Not for a view controller created in isolation by a unit test."
– Jon Reid
Nov 20 '18 at 5:04
OK, we're on the same wavelength. But then you and I are just saying the same thing (which is fine): the problem has nothing to do with the fact that this is a unit test but rather (as I say in my answer) that the text field is not in the interface and cannot become first responder. Non-unit test code, too, could create a free-floating view controller whose view isn't part of the interface, and would get the same result.
– matt
Nov 20 '18 at 5:08
OK, we're on the same wavelength. But then you and I are just saying the same thing (which is fine): the problem has nothing to do with the fact that this is a unit test but rather (as I say in my answer) that the text field is not in the interface and cannot become first responder. Non-unit test code, too, could create a free-floating view controller whose view isn't part of the interface, and would get the same result.
– matt
Nov 20 '18 at 5:08
There are tricks like "place in a view hierarchy" and "pump the run loop" that work for first responders. Such tricks are unusual, thankfully.
– Jon Reid
Nov 20 '18 at 19:02
There are tricks like "place in a view hierarchy" and "pump the run loop" that work for first responders. Such tricks are unusual, thankfully.
– Jon Reid
Nov 20 '18 at 19:02
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53380233%2fuitextfielddelegate-not-called-in-xctestcase%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
