-
Notifications
You must be signed in to change notification settings - Fork 913
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
Add support for dismissing system alerts #510
Add support for dismissing system alerts #510
Conversation
* Links against the private UIAutomation framework to access UIAtarget, UIAElement, UIAAlert, and UIAApplication * Only works on iOS 8.1 * Will fail if alert does not show up (eg. permission was already denied or accepted)
Now with iOS 7 support the build on CI is passing! |
This is absolutely fantastic! Amazing work. Now that you have cracked open the automation server, KIF might be able to do all kinds of new tricks with other system dialogs. |
Add support for dismissing system alerts
👍 Just a heads up that there is definitely some polish that could be done. For example:
Would you like me to open new issues for each of these or just keep them tracked here? |
How about just opening one issue that covers the three points you raised above? |
I added the three points to issue #512. |
This is really amazing, well done! I didn't know it was possible to do - clever tick using UIAutomation. Am I right In thinking this will only work on the simulator? |
I am having issues using - (void)acknowledgeSystemAlert with an iPhone 6 Plus simulator. Was this working for you locally? |
@maxwellE What issues, exactly, are you running in to? |
Further developments with my issue, if I run our tests with the 7.1 simulator instead of the desired 8.1 simulator then the tests succeeded and are unaffected by the simulator locking up. |
On an iPhone 6 Plus the acknowledge method just locks up the simulator and hangs forever. On Dec 9, 2014, at 8:00 AM, Jamie Forrest <notifications@github.commailto:notifications@github.com> wrote: @maxwellEhttps://github.com/maxwellE What issues, exactly, are you running in to? — |
Will this work for the camera alert? When the Camera alert opens, the kif test just sits there and doesnt move onto the I have a step that wants to access the camera and after clicking that the alert pops up. How do I call the kif step to close the alert if it doesn't move on?
|
@maxwellE and @OliverPearmain - I took a look at this last night and have a few updates. PR #520 restores on device testing by not linking against the Unfortunately this does not address the issues you are seeing. If you clone master and run the included test suite does the simulator still hang? If so then we have some more digging to do. If not, can you provide sample code that reproduces your issue? |
I'd love to have a way to dismiss the update alert. Thanks for this awesome use of UIAutomation! |
It not work on IOS 8.4 for location alert :( |
@iMaximus can you file a new issue with more details? Thanks! |
Sorry, my bad. I thought that not work method [tester acknowledgeSystemAlert]; for location alert on simulator iphone 6 (8.4) but all work correctly. |
@Tom-Wolters Which method? |
@phatmann I apologize - The method ('acknowledgeSystemAlert()') is working as intended! I removed my comment. |
Im using KIF in swift , I cannot have the method acknowledgeSystemAlert(), how can I call this method ?? |
It is available on |
right , My target was device so I wasn't able to see the function! |
Gotcha, we do all of our testing on iOS Simulators, so we don't have this issue. I believe we can't load the UIAutomation.framework on devices in order to interact with system alerts unless you have a jailbroken device, at which point it should be theoretically possible (though I haven't tried). Rather than relying on these methods to interact with system alerts, you should be able to swizzle some methods to stub the behavior that ends up popping the system alerts. I posted in #979 with our workaround for how to suppress the CLocationManager alerts. We do something similar for the photo picker as well. |
You are totally right! |
For those damn update pop ups we run our WiFi connections through a proxy and blacklist the apple sites. We use privoxy. |
Regarding not wanting to stub the behavior of accessing the photos or location, at least philosophically for me, it isn't testing behavior that is within your control. As long as you're conforming to the same API contract that is exposed by Apple's API, it shouldn't be necessary to actually test the iOS system behavior IMO. |
Hi, I found that applicationState is always |
This is a first pass at dismissing system alerts (eg. location services and access to photos). It works by linking to the private UIAutomation framework and then calling down the
UIAElement
chain to grab the alert. It then taps the last button which should be the Allow one.Also of note is how the private headers are pulled in. In its current state all the knowledge lives in
KIFSystemAlertHandler.m
and only exposes the required methods. Take a peek at the full header dump and the inspiration for this if you are interested in seeing the full list. There is also the option of pulling one of those in as a Cocoapod and keeping all the knowledge contained there.This could be a solution for PR #507 running on CI but I want to first make sure this is an acceptable approach before continuing. If so, please let me know and I will continue with adding support for iOS 7.X and not failing the test if the alert never shows up.
While this will not yet allow interaction with external views (eg.
ABPeoplePickerNavigationController
), it does mark a huge step forward for KIF being able to interact with elements outside of the standard accessibility hierarchy.