How to Get Started with XCUITest on Real Devices on Cloud
Developing for iOS applications is a popular field. Enhance your skills by learning how to run iOS tests with Apple's XCUITest platform.
Join the DZone community and get the full member experience.Join For Free
apple’s xcuitest has quickly become very popular among ios app developers, and testers as well. we’re extremely excited about this framework as it has enabled many of our users to adopt a new framework since ui automation was deprecated . the xcuitest framework is not really new, as its foundation, xctest, has been a part of the xcode for some years already.
let’s take a look at xcuitest and how to get started with it, and run your tests on remote real devices on a cloud service.
mobile apps and games created for ios devices can be tested using various different test automation frameworks . apple has provided its own ‘official’ test automation frameworks, such as xctest and xcuitest , as an integral part of xcode. and as they're both tightly integrated with xcode, both xctest and xcuitest support writing test cases with subclasses, methods, and assertions.
naturally, both of these frameworks are available and supported with bitbar testing solutions, and this blog provides all the details of how to get tests up and running on bitbar public cloud using xcuitest.
step 1: configure your app for unlimited parallelism on real devices
concurrent mobile test runs are a very important factor for your efficiency and productivity, and how to use test automation to improve these. there is really only one thing you have to check to ensure your app is able to run on any of the ios devices in the bitbar public cloud. open the scheme editor and verify that in the run column all test targets are checked (enabled).
now, check that all classes that you want to include in the test bundle are properly included with the test target membership.
note! if you are using swift, annotation @testable imports all required modules for the test bundle.
step 2: the right way to build your ipa and test package
the next step is to build your application ipa and test package the right way. in order to do this properly, you should follow up all these steps to ensure the app is able to be installed, launched, and executed in any of the ios devices in the bitbar public cloud.
if you are not familiar with these frameworks, check out the xcuitest tutorial for ios app testing .
now, regardless of which framework you are using (xctest, xcuitest, or something else), the application under test needs to be built and imported to the bitbar testing cloud. the following steps show you how to create an ipa that is executable on ios devices.
in xcode: click product -> build for -> testing .
finally, when you are building your ipa and test package for the bitbar public cloud test run, you should always build your app using a real device as a build target, as shown below:
the built application must also be packaged to zip file. the easiest way to do this is to use xcode’s preview and right click show it in finder above the right .app file.
in finder, right click the .app file and copy its path. this path does not change from build to build, so this step only needs to be done once.
the ipa package needed for xctest in the bitbar public cloud is a zip package and its creation can be automated and made part of a ci integration. open a terminal and create the ipa as follows:
$ mkdir /tmp/payload $ cd /tmp/payload $ cp -r /users/username/desktop/build/products/debug-iphoneos/localizationdemo.app . # app path can be pasted $ cd .. $ zip --symlinks -qr "localizationdemo.ipa" payload $ ls -lrt localizationdemo.ipa -rw-r--r-- 1 username staff 0 dec 16 12:42 localizationdemo.ipa
note! if you build for iphone 5 or iphone 5c devices (with armv7 32-bit processor) then an additional step is needed before creating the build. starting from xcode7 onwards, armv7s is no longer part of the default $(archs_standard), and so should be added as a target build architecture.
step 3: login to the bitbar cloud and create xcuitest project
after you have followed all above steps, just log in to the bitbar public cloud and create xcuitest project from projects menu.
step 4: upload your application ipa and test package
start by clicking the green plus button on the top right corner of the view. this will open a test run creation wizard that helps in correctly setting up all of the parameters for your test. the test run creation wizard asks for both the application file (ipa) and the test package (.zip).
this is very handy, because you don’t need to change the app or test package, and you don’t have to upload it again; but the old one previously uploaded can be used for a test run.
step 5: select any number of ios devices for your test run
this is where the real benefit of bitbar cloud execution comes into play. you can use any number of ios devices for simultaneous test runs (we’re not limiting the number of concurrently used ios devices anyhow!). so, pick the devices you want for a test run on the test run creation wizard step number 3.
after this is done, simply click through the wizard and start a test run. the green start button is available in all phases of the test run creation wizard on the bottom right.
all done! now, let’s take a look at the results!
the first thing to do after test runs are ready is to check how it did on devices you picked for a test run. the first view provides details of test success/failure on each and every device. this view also provides information on how long the test runs took.
bitbar solutions provide all the details about the test runs and this includes recorded video of the session, screenshots, logs, performance statistics, and all fine-grained details about device session. all this material will help you to fix and shape the app to work better on real devices, the very same devices that your end-users use.
bonus materials for xctest and xcuitest
more details and instructions on how to use xctest and xcuitest for your test purposes and how to exercise those with the best practices can be found on slideshare .
Published at DZone with permission of Ville-Veikko Helppi, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.