Last day of year 2014 and what better than writing a post about my most interesting research of this year for the Salesforce Mobile SDK! In the previous post, we learnt about the need and challenges associated with mobile automation testing in general. Now, let’s move forward and explore an example with some uses cases of typical mobile automation requirements in Salesforce1 apps.
Let’s consider the sample AccountEditor hybrid app that’s shipped with the Salesforce1 Mobile SDK to identify some automation use cases.
Here’s a demo video of the typical operations of the AccountEditor application.
Automation Use cases
The main features of this app that we would like to automate are
- Salesforce oAuth authentication
- Create new account
- Edit existing account
- Delete existing account
- List accounts and account information
The app also provides advanced functionality such as being able to create records offline and then sync them back to Salesforce once Internet connectivity is restored. However, for the sake of simplicity, let’s omit that from our list of automation use cases for this app.
Now that we understand how this sample app works, let’s get our Appium test setup ready.
How to launch Appium?
First, launch the Appium application and it will show a window as shown below.
Next, click on the Apple icon and configure the app parameters as shown below. Chose the AccountEditor.app file (not the ContactExplorer.app file)
Next, click on launch to open the Appium Inspector. This opens a window on the left which shows the emulator or device with your app launched.
How to identify various UI elements?
The first step is to automate the oAuth login flow. So, we need to do the following operations
- Bring focus to username field
- Tap on username field
- Enter the username value
- Bring focus to password field
- Tap on password field
- Enter the password value
- Bring focus to Login button
- Tap on password button
- It will then prompt for permissions (Allow/ Deny) so tap on Allow button
Assuming that we enter the correct credentials, we should then be able to authenticate successfully.
Let’s see how this works.
Note how we search for each element by drilling through the navigation hierarchy and then enter it’s value. Sometimes, the emulator/ device screen does not refresh by itself so you should click on the ‘Refresh’ button in Appium Inspector to do a manual refresh if required.
Yay – so we’ve now automated the login flow and it’s now time to look at automating the CRUD operations in this app.
In the above, Appium is using the JSON WebDriver to detect each UI element and then we’re programatically firing each event as required. The most interesting thing is that Mobile SDK uses WebView for an oAuth so if you’re doing physical inspection of UI elements (similar to how Selenium does using xPath) rather than using the WebDriver, it will not be able to detect any UI elements on the login screen.
Thankfully, this is one of the key features of Appium inspector is that it’s able to work well with WebViews.
First hurdle crossed and we will now move to bigger challenges to pluck elements from the app UI and automate those operations. And finally, we’ll try and put everything together as a project which can be run with any CI (Continous Integration) solution such as Greenhouse or Jenkins to achieve end to end automation.
See you next time!