Writing UI test in iOS with XCUITest in objective-c for React Native

Gergő Nagygyörgy
3 min readMay 26, 2018

I am going to write about my experiences writing UI tests for iOS in XCUITest, running them in Microsoft’s AppCenter, and all the troubles i went through, not about the basics of UI testing.

Writing test

We can chose to write the test in swift too, but i decided to do in objective-c. For us to be able to query for UI elements, we are going to use an out of the box solution called testID property. This way we can assign unique identifiers to our elements. Then search for them in the tests, and then simulate user interactions.

Accessibility

To UI test on Android, we have to use accessibilityLabel with accessible property set to true on the react component. Than we can query for elements and write the tests we want.

But on iOS we cant query items which has accessible property set to true. All the touchable component’s accessible property true by default. So if our desired element is wrapped in a touchable, than we have to explicitly set accessible property to false. Or, if its set to true, because of Android UI tests, than you can need to assign the appropriate Booleans depending on the OS the code is running on. For example.

accessible={Platform.OS == ‘ios’ ? false : true}

Getting stuck on ‘Wait for … to idle’

My tests got stuck on this message (it’s in the output window). If we were to manually scroll down, and than back top, the tests were continue to run without getting stuck. People of the internet suggested that there is a long running animation blocking the test. I tried disabling View animations, but it did not helped. The other option was to suppress the ‘Wait for <bundle name> to idle’ message. Which i managed to do with the following code, which has to be called once in the test’s (void)setUp method.

credit: https://stackoverflow.com/a/48766737

Running UI tests in AppCenter

Looking at the devices, there are no visual clue of any errors in the application. There is an annoying notification on one of the devices, but its fine since its going to disappear within a couple of seconds.

Calling the label function each time, the test cloud takes a screenshot of the phone screen, and we can check each of those steps of how the application looks like on the devices we selected to run the tests on.

Test summary page

This is the first details page we can check out during and after the test run about our tests, and how well they perform.

Test run summary page

After selecting one of the test labels we can have a look at the screenshots taken on the real devices while our tests were running side by side. In the test, we have to call a label function with the a string parameter which is the trigger to take the screenshot for the test report.

Labels and the appropriate screenshots

We can check the individual test run statistics by phone. This includes memory and CPU usage diagrams, logs from the test runner and from the device itself.

Test run details by device

And the tests:

At the end of the day, ui testing is not rocet science, it can be helpfull
if you do it in general, and in developing for mobile, running these tests on many different kind of phones(not on emulators!) helps detecting error(s) which can be manufacturer or model specific really easily.

I keep the source code for myself for now. The application is available on Apple’s App Store and on Google Play Store.

--

--