-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Textview not accessible to UI tests #63
Comments
Ah, it looks like the iOS Accessibility Programming Guide explains (inc. sample code) how to make the contents of custom container views accessible. Unfortunately we don't have any Obj-C expertise in-house to try out this implementation. |
Hey @jamesbebbington. Sorry, but I don't have the capacity to implement this change. |
Hey @jamesbebbington, I've looked a bit into this and the Thanks! |
Thanks @fphilipe, much appreciated. UI tests can now address the text view, however I'm seeing some strange behaviour when programatically entering text. Given this UI Test case: import XCTest
class PHFComposeBarViewExampleUITests: XCTestCase {
override func setUp() {
super.setUp()
continueAfterFailure = false
}
func testComposeBar() {
let app = XCUIApplication()
app.launch()
app.staticTexts["PHFComposeBarPlaceholderLabel"].tap()
app.textViews["PHFComposeBarTextView"].typeText("Here is some sample text. It's a few lines long but not too long. I think that should do it.")
app.buttons["PHFComposeBarUtilityButton"].tap()
sleep(5)
}
} the entered text is being partially erased as it's entered:
EDIT: I forgot that I had set the accessibility identifiers in the the example app. Test code above updated and pushed in new Thanks! |
I've pushed a couple of updates to the ui-tests-2 branch, fixing the misnamed buttons and adding a (failing) assert that checks that the entered message was properly saved. |
@jamesbebbington thanks! I've added a commit introducing a test (based on yours). I was not able to reproduce your erasing text problem you showed in the GIF. I'm wondering if the accessibility identifiers should be set directly in From my side this would be ready. Let me know if this works for you. |
Cheers @fphilipe, will take a look now.
I don't think it matters too much either way, as long as consumers can set them. I think it's probably fine to leave them unset, as I'd imagine anyone who wanted to use them would want to rename them anyway. |
Yeah, it's an odd one, it seems a bit intermittent. I integrated the
Yup, many thanks @fphilipe! |
Hey @fphilipe, we have an app that makes much use of PHFComposeBarView and as we're aiming to translate it into a couple of dozen languages, we're very keen to make use of UI Tests to automate UI testing, screenshots and video walkthroughs for our translators. Unfortunately we're having problems entering text into the ComposeBar programatically.
It looks like the core of the issue is that the text view is not visible to the underlying accessibility framework that UI Tests depend on.
I've created a minimal test case using your Example app that exhibits the issue. While it's possible to tap the ComposeBar and give the textview focus, the test framework then can't find any textview to type text into.
I've added some
acessibilityIdentifiers
to help make addressing specific elements easier, but if you look at the application's element subtree that's dumped to the test log, you should be able to see that there's no sign of any textview:I suspect that this may be related to the fact that the textView is a child of a button, as brought up in #36. I'm sure you had good reason to nest the textview in the button, I'd much appreciate it if you could give us some background so that we can fix or workaround this issue.
Many thanks.
The text was updated successfully, but these errors were encountered: