UI Tests no longer working on Xcode 7.3 - ios

I have a set of XCUITests that run with our iOS app. They used to run fine on Xcode 7.2.1, but upgrading to 7.3 causes tests to fail in the "Set Up -> Wait for app to idle" phase with the following error:
UI Testing Failure - Failed to perform AX action for monitoring the animations of <XCUIApplicationProcess: 0x7f82450288c0 [appName here] (25670)>, error: Error -25204 performing AXAction 2043
This failure is seen on every single UI test, both on bots and when running locally.
Has anyone else seen this or have any workarounds?

In case anyone still has this issue - for me it was activating the Optimizely framework that caused this error. Disabling the framework when running XCUITest solved it for me.

Note to self: Don't have code that crashes your app on purpose while tests are trying to run. D:
Basically there was a call to terminate the app within the launch phase of the app for a certain scheme (in our case, the TEST scheme). Be thorough in checking what the app is doing when it launches for testing, because there might be errant behavior.

Related

iOS UITests failed: IDETestOperationsObserverErrorDomain Code=13

I am running an AppUITests for an iOS app from Jenkins build script. Unit tests (AppTests) running fine but AppUITests are failed because of the below issue. How can I resolve this issue?
09:19:53.506 XCTRunner[22911:77924] Failed to background test runner
within 30.0s. 09:19:53.507 xcodebuild[22835:77541]
-[IDETestOperationCoordinator testRunnerSession:initializationForUITestingDidFailWithError:]
09:19:53.507 XCTRunner[22911:77924] Calling completion. 09:19:53.507
xcodebuild[22835:77541] Test operation failure: Failed to background
test runner. 09:19:53.507 xcodebuild[22835:77541]
_finishWithError:Error Domain=IDETestOperationsObserverErrorDomain Code=13 "Failed to background test runner."
UserInfo={NSLocalizedDescription=Failed to background test runner.}
didCancel: 1
I had the same issue in our app. It was caused by a permission alert displayed on launch (APN in this case, but it's likely to be the same for any other alert).
Steps to reproduce
use an app which will display a permission alert on launch
make sure the simulator is clean (in order to show the alert)
run all Tests
Result
app launches, shows the alert and runs the (normal) Tests just fine
BUT when coming to UITests, the simulator will stay black and after a short while, it fails with following error:
Error Domain=IDETestOperationsObserverErrorDomain Code=13 "Failed to
background test runner.
Solution
Run the UITests before the normal Tests (just change the order in edit scheme => Test => Info)
Notes:
Maybe you have to make sure, the UITests will handle the alert by using XTests addUIInterruptionMonitor method. Or otherwise it could be possible the (normal) Tests will fail the same way (didn't test this scenario).
If you really don't want to run the UITests first, you could add an additional UITest target, which is run first, and just handles the alert. Then you should be able to run the (normal) Tests followed by your UITests.
Related
https://discuss.bitrise.io/t/test-ui-xcode-9/2313

"[Crashlytics:Crash] Reporting is disabled"

I am getting the following error messages when our production iOS app initializes:
[Crashlytics] Version 3.8.4 (121)
[Crashlytics] Running on iOS Simulator (iPhone), 10.3.0 (16E195)
[Crashlytics:Crash] Reporting is disabled
[Crashlytics] Crash reporting could not be initialized
[Answers] Initialized
[Fabric] Initialized with kit versions: {
"com.twitter.answers.ios" = "1.3.4";
"com.twitter.crashlytics.ios" = "3.8.4";
"io.fabric.sdk.ios" = "1.6.11";
}
Every subsequent call to log an event gets the following error:
[Crashlytics:Crash] WARNING: CLSLog has been used before (or concurrently with)
Crashlytics initialization and cannot be recorded. The message was: ...
The non-production versions of the app work fine running the exact same code but with different bundleIDs. Normally when the app initializes for the first time, then I see the app populate in the Fabric dashboard, but in this case the app is not showing up.
We have an Android and an iOS version of the app, and they both use the same bundleID, so I am wondering if there is a conflict because of that? I see the Android version of the app in the dashboard, and it seems to be working properly. This is an app that originally was a Xamarin app that compiled to both platforms, neither of which incorporated Fabric/Crashlytics. We have now written native apps on each platform, and both are using Fabric/Crashlytics.
Since this is a pre-existing app in both stores, we do not have the option of changing either app’s bundleID.
Make sure you initialize Crashlytics with Fabric before calling any Crashlytics methods:
Fabric.with([Crashlytics.self])
One step I routinely miss is to make sure you've added the build phase on your target:
"${PODS_ROOT}/Fabric/run" ${FABRIC_API_KEY} ${FABRIC_BUILD_SECRET}
and either replace ${FABRIC_API_KEY} and ${FABRIC_BUILD_SECRET} with your key and secret or add custom build settings for each.
There are apparently cases where Crashlytics does not auto-activate new apps so that they show up under your list of apps, even though everything is coded correctly and data is going to their servers. In this case, send an email to Crashlytics support (support#fabric.io) that contains a copy of the info.plist entries for the app in question and they will activate it for you. I have had to do this several times, especially with app extensions.
When I finally traced it down in my situation, the error was entirely correct, but not obvious.
I saw these errors in various testing targets where the code we tested was using a custom logging wrapper which called CLSNSLogv(), but the test didn't actually go through the AppDelegate and therefore did NOT initialize Crashlytics. After trying a few things I was convinced that it worked when executed as an app, but in our configuration it was not working under the unit test configuration.
I'll likely alter our custom wrapper to bypass CLSNSLogv() during testing anyway. The biggest benefit of using that is when crashes occur on devices, so we won't be missing anything.

IOS bot error: Early unexpected exit, operation never finished bootstrapping -

I have a question regarding build error that occurs when bots perform UI testing.
When I just run the UI tests, it just works fine. However, whenever I use bots to run the UI tests, there is build error and I keep getting build error saying:
"Early unexpected exit, operation never finished bootstrapping -"
XCode bot error: Early unexpected exit, operation never finished bootstrapping -
Some proposed solution says that I have to skip the APNs.. In my case the alert came up since the application was trying to register of APNS and the
"App Name" would like to enable Notifications alert was displayed. Skipping the APNS registration for UI Tests will prevent the issue from popping again.
How can I confirm that the alerts are causing the problem? I was not able to check it since simulator shows nothing on CI machine when the tests are performed by bot. Also, could you please specify what steps should be taken to skip the APNS registration for UI Tests? I am using iphone 6s simulator.
I have been stuck here forever.
I would really appreciate your help!
Thanks!
The solution that worked for me was to use iphone 6s simulator (iphone 6s or iphone 6s plus). I was using iphone 6 and it caused me a lot of errors including this one.
The actual reason was that APNS registration could not be skipped using iphone 6 simulator whereas it could be skipped using iphone 6s simulator for me (App would like to enable push notification..). After that, addUIInterruptionMonitorWithDescription successfully worked for me!

Simple XCTest for UITest is failing all the time?

I start a new project from File -> New -> project
I add a button to ViewController.
I open UITest folder which created by xcode by default. Run the test code.
It fails:
2016-03-16 12:57:09.191 XCTRunner[3511:150419] Continuing to run tests in the background with task ID 1
t = 10.18s Assertion Failure: UI Testing Failure - Failed to background test runner.
/Users/Bernard/Desktop/ExampleTestApplication/ExampleTestApplicationUITests/test2.m:27: error: -[test2 testExample] : UI Testing Failure - Failed to background test runner.
2016-03-16 12:57:12.789 XCTRunner[3511:150419] *** Terminating app due to uncaught exception '_XCTestCaseInterruptionException', reason: 'Interrupting test'
Now I add a break point as follow:
Now test is successful! Anyone can explain the reason?
I was also facing same issues and none of the available solutions worked for me. Issue was not letting app to attach to the simulator itself.
I checked the log and saw that i did a mistake in code while locating the element. for Predicate instead of BEGINSWITH i wrote STARTSWITH and this was stopping the app to get attached.
So check your logs in the test report to get the issue.
I was getting this error happening when the iOS simulator was already launched (which may not necessarily mean you can see it in the OS X dock). You can check the state of the various simulators using the simctl command.
I.e.
xcrun simctl list devices
Then, ensure that any devices listed as "Booted" are shutdown:
xcrun simctl shutdown <device-udid-here>
Then, try running your UI tests again.

App crashes before debugger can connect

I've got an app that crashes even before the debugger can connect.
I placed a break point on the first line of main(). (I added an NSLog statement as very first statement in main() and set the break point there.
The app seems to start. The main screen with some ui elements becomes visible on the screen. Then it disappears.
There is no crash log found on the devices.
Xcode message:
Could not launch "appname"
process launch failed: failed to get the task for process xyz
Debugging is enabled of course.
The same for the profiler Instruments.
Code signing works fine so that the app can be deployed to the devices.
(Same for enterprise distribution. And the app validates for store submission.)
It does work on the simulator though.
The app used to work fine. I was just about to build it for the store. For final tests on iOS 8.1 I upgraded to Xcode 6.1 with SDK 8.1. But the problem did not occur directly after the upgrade. It worked just fine.
Then it crashed when building for release for enterprise distribution.
The AppStore build crashed in the same manner (according to Apple, the app was rejected of course.)
But it ran nicely in debug modes.
Now I was trying whether compiler options for optimization may make all the difference and I was trying to build in release mode with debugging enabled etc and end up with a debug build crashing as well. (No optimization in debug).
So it may well be that the migration to Xcode 6.1 did cause it but the problem may have come effective only after Xcode cleaned and rebuild the project in response to changes to compiler settings for code optimization.
Sorry for the long text. I tried to put everything in that may be of importance.
Reason is most likely some incompatibility of Crackify and iOS 8.1.
Therefore it may be of interest for others, altough my problem along with these symptoms may be very special.
Very early within AppDelegate didFinishLaunchingWithOptions we have had the following statement.
if ([Crackify isCracked] || [self isCertificateUnvalid])
exit(173);
That, as such, is not really well designed. The app is just terminated rather than any error message displayed to the user. Thus, it appears as if the app has crashed. But it has not crashed and therefore no crashlog is provided.
For reasons which I don't yet understand and which may not be related to this error, my debugger did not manage to hook up into the executed app. Once that was overcome (suddenly the debugger worked without any changes made to any of the debugging related settings) the error was found rather quickly.
This is Crackify: https://github.com/itruf/crackify
Within Crackify it was this code sniplet that caused the problem:
static NSString *str2 = #"ResourceRules.plist";
BOOL fileExists3 = [manager fileExistsAtPath:([NSString stringWithFormat:#"%#/%#", bundlePath, str2])];
if (!fileExists3) {
return YES;
}
For reasons that I did not further investigate, the file, that is tested here, apparently does not exist in iOS 8.1 any more.

Resources