The development process of iOS applications has drastically evolved during the following years, and nowadays everyone is hyped by using some specific architecture, writing unit tests, improving the application, etc. This is very important for today’s market, where each company is racing with it’s competitors to deliver new feature to their customers, in order to gain more revenue. This sounds really cool, but when people are under high pressure tend to make mistakes. That’s why automation testing comes to play, and ensures that the application is stable during the continues integration (CI) builds. In the following posts I’m going to explain the process how to automate your iOS application.
Before you get started
The demo that I have prepared is using the Behavior Driven Development (BDD) approach, and it is going to be quite similar to my previous Android Demo post. The code structure is going to be quite similar to the code structure of the Android demo, but there are some differences into the environment, configuration and the simulator. The application that is used for the demo is the default iOS Contact application that could be found on each simulator / device.
The following is required for running automation tests for iOS application:
- Appium application
- Xcode 8
Most of you are going to be surprised that Xcode is required, and the demo is written in Java. The reason for this is that Xcode is required by the Appium application in order to inspect the UI elements. In the following sections I’m going to describe the code structure of the project, the configuration, and the parts that you have to pay attention when you start automation testing for iOS.
The structure of the project is the following:
- Base folder
- Screens folder
- Steps folder
- Features folder
Base folder is used for storing the class for reading the configuration, and the driver helper class used for inspecting the elements.
Screens folder is used for storing the classes that contain the logic for interacting with the elements on the displayed screen, for example: Contact Info screen, Contact List screen, etc.
Steps folder is used for storing the classes that contain the implementation of the steps defined in the feature files.
Features folder contains the .feature files with the Scenarios and their steps.
If you have read the previous posts about Android automation, you have noticed that I have placed App folder in the code structure, and in this code structure this folder is omitted. This folder is omitted because the application is already pre-installed on the simulator and the device. If you have .ipa file, you can place the .ipa file in the App folder and run the automation tests configured to use the .ipa file.
Before using .ipa application file, you need to make sure the application is signed as application that could be installed outside App Store, otherwise the application is not going to work.
The configuration file can be found in the following directory resources/config_app.properties. Briefly I’m going to go through the properties, and afterwards you are going to notice the difference.
explicit.wait=30 application.path= base.pkg=com.apple.MobileAddressBook appium.server.port=4723 automation.instrumentation=XCUITest platform.name=iOS device.name=iPhone 7 device.udid=FB8F39FD-7658-450E-A91E-007256C1E838 platform.version=10.2
If you’ve read my previous posts about Appium automation on Android you are going to be familiar with the properties, and find the differences between the configurations. Anyhow I’m going to go through the properties again, that way it would be easier to spot the differences.
explicit.wait – This property is used to indicate the explicit wait time for locating the element.
application.path – This property is used to hold the location of the .ipa file that has to be installed. If the .ipa file is already installed or your tests does not require the application to be installed every time when a test is executed, this property can be left empty.
base.pkg – This property is used to hold the bundle name of the iOS application.
appium.server.port – In this property add the Appium port, the default value is 4723.
automation.instrumentation – In this property is set the instrumentation that is going to be used for automating the scenarios. In this case should be set as Appium.
platform.name – In this property is set the platform name that is going to be used, in this case should be set with iOS.
device.name – This property contains the device name on which the automation tests that are going to be executed.
platform.version – This property contains the iOS version of the device, on which the automation tests are going to be executed.
device.udid – This property contains the UDID of the device, it is unique identifier for each simulator, and iPhone device.
The configuration difference between Android and iOS is between the following properties: automation.instrumentation, platform.name, device.name, and the new property device.udid.
To be continued
At this point I’m going to end the first part of the post, which had different structure from the previous post, but I guess it would be more intuitive to understand the concept of automating iOS applications. In the next post I’m going to focus in more detail about the code structure, how to initialize the driver, and where to pay attention in order to speed your appium automation tests.