In the previous post I have talked about the iOS driver initialization, and its configuration, and few tips that are going to help you while writing the automation tests. But before you start writing the automation tests you need to know which location strategy to use in order to locate the elements. That’s why in this post I’m going to write about the element location strategy, how to inspect the elements and which attributes to use for locating the elements.
Let’s get started
Before we start to inspect the elements first we need to start the Appium server, and this could be easily accomplished by running appium in cmd, or ./node_modules/.bin/appium depending on the Appium location on your work machine. If the following message is displayed on your console, means that the Appium server has been successfully started.
[Appium] Appium REST http interface listener started on 0.0.0.0:4723
We are one step closer to inspecting our iOS application, the next step is to run the Appium application. As discussed in my previous automation post for Android I’m going to run the Appium server and the Appium application separately. This approach may look a bit complicated, but it is going to allow you to have the latest the latest Appium version, and still use the Appium inspector.
On the screenshot below it is presented the Appium iOS settings required for running the inspector.
Before going any further lets stop here a little bit, and analyze the meaning of the iOS settings;
App Path – Is the path to the application that is going to be tested. (This field should be populated if we have the .ipa file or the application is not installed on our device)
BundleID – Is the bundle id of the iOS application, in this case it is the bundle id for the default Contacts application.
Force Device – This field is used to let Appium know which iPhone device / simulator is going to be used for running the automation tests.
Platform version – This field is used to let Appium know which is the iOS version of your device / simulator. In my case the iOS version of the simulator is 10.3
UDID – This field is used to let Appium know the UDID of your device / simulator. This field is usually used when running the automation tests under real iPhone device.
Force Orientation – This field is used to force the orientation of the device / simulator, portrait / landscape.
Force Language – This field is used to force the language of the device / simulator. This is handy when you have to test the application localization.
Force Calendar – This field is used when you want to use different calendar than georgian.
Force locale – This field is used to set the locale of the device. This is handy when you have to test the application localization.
Show Simulator Log – If you want to see logs while you are navigating the iOS application, then you should check this field.
Show iOS System Log – If you want to see logs from the iOS application than you should check this field. These are the logs which are logged with the NSLog(@”This is dummy log.”); function.
Great, we are almost there! Now for running the Appium inspector just click the magnifying glass i.e. the search button. You have noticed that we haven’t touched the Launch button in the Appium application. This is because we have started the Appium server in our first step. In the screenshot below it is displayed the Appium inspector screen.
In my case I have opened the Contacts application, and this is the first screen that is displayed when the Contacts application is opened. The easiest way is to take a snapshot of the device / simulator, and afterwards by clicking on the snapshot on the right side you can view the details of the UI element.
When inspecting the UI elements in the iOS application the following details are going to be available:
- Name – The value of the name attribute
- Type – The XCUITest type of the element, note the UI type is different than the native iOS UI elements, UILabel, UIButton, UITextView, etc…
- Value – The value of the value attribute.
- Label – The value of the label attribute.
- Hint – The value of the hint attribute.
- Enabled – This flag shows whether the UI element is enabled or disabled.
- Visible – This flag shows whether the UI element is visible on the UI.
- Valid – The value of the valid attribute.
- Location – The location of the UI element displayed on the screen.
- Size – The size of the UI element displayed on the screen.
- Xpath – The absolute Xpath locator for the UI element.
My approach when inspecting the UI element is to use the Touch location strategy, this way you can easily find the element and view its details. Afterwards you can choose your best location strategy of the UI elements in your automation suite. Keep in mind that when touching the element you may touch other UI element which are on top of the UI elements displayed on the snapshot, in this case you should use different inspection strategy, or check the XML document to check the UI element.
Most newcomers to automation test tend to automate the scenarios by recording the actions which are executed. This is fine as long as you don’t have to automate numerous number of automation tests, or you are curious to see the generated code. But if you plan to create automation suite for long term, that is going to help you with your testing process, than in this case you should consider using proper architecture when developing the automation tests.
Another reason why you should not relay on recorded automation scripts is the location strategy, this means that with the slightest change in the UI elements order in the XML node, the automation test is going to fail, and you are going to have to record the automation scenario. Which is going to become one messy code that you are going to spend more time on maintenance rather than actual automation tests development.
In this post you have become familiar with the Appium settings for iOS, Appium inspector for the iOS application, how to inspect the elements, which locator strategy to use, view the UI element details and use their values. Why you should consider using proper architecture for the automation tests instead of recording the scenario. With this post I’m going to end the automation testing with Appium for iOS application. I hope you liked 😉