Speed Up iOS Appium Test Automation


     Appium users have the question like how to speed up the iOS tests, citing the length of time it takes to start tests which use the WebDriverAgent library (all tests using the XCUITest driver).

     Most of the perceived speed of an Appium test can’t be improved due to the base speed of booting devices or the UI actions themselves. The slowest part, which users were asking how to avoid, is the initial startup of a test: the time between sending the first POST /session command and the response indicating that your test script can begin sending commands. We can call this time period the “session creation” time.

     There are desired capabilities we can specify to greatly reduce the time it takes to create a session. Appium is built to cater to a large number of devices, for use in many different situations, but we also want to make sure that it is easy to get started automating your first test. When specifying desired capabilities, Appium will analyze the state of your system and choose default values for every desired capability which you don’t specify. By being more specific, we can have Appium skip the work it does to choose the default values.

     Our first improvement is to set the app location to a file already on the host device. Then you can directly use the bundleId 

caps.setCapability(“bundleId”, “io.test.app”);

      Please ignore the remote path of your application in the code instead of that you can use the local application path, once it gets installed on the device avoid the local path and stick to use bundleId

     Running the tests, it’s easy to notice that the app gets reinstalled on the device for each test. This takes a lot of time and can be skipped. You may have certain tests which require a fresh install or need all the app data cleaned, but those tests could be put into a separate suite, leaving the majority of tests to run faster by reusing the same app. Most users should be familiar with the noReset desired capability.

 caps.setCapability(“noReset”, true)

    Appium uses the simctl command-line tool provided by Apple to match the deviceName desired capability to the udid of the device. We can skip this step by specifying the device udid ourselves.

caps.setCapability(“udid”, “009D802528AB4A1BA7C885A9F6FDBE95”);

      When loading the WedDriverAgent server, Appium loads the files from wherever XCode saved it after compilation. This location is called the “Derived Data Directory” and Appium executes an xcodebuild command in order to get the location. Below desired capability derivedDataPath allowing Appium to skip the work of calculating it:

caps.setCapability(“derivedDataPath”, “/Users/sanojs/Library/Developer/Xcode/DerivedData/WebDriverAgent-apridxpigtzdjdecthgzpygcmdkp”);

     The last optimization is to specify the webDriverAgentUrl desired capability. If specified, Appium skips a step where it checks to make sure that there are no obsolete or abandoned WebDriverAgent processes still running. The WebDriverAgent server needs to already be running at this location, so we can only use this desired capability after the first test starts the server.

caps.setCapability(“webDriverAgentUrl”, “http://localhost:8100”);

       I hope the above tips will help you to speed up the iOS automation using Appium. Please try to change your Desired Capability today to get a better speed of automation on the iOS platform.

Refer the tips to improve the speed for Android @https://journeyofquality.wordpress.com/category/speed-up-android-appium-test-automation/

Reference: Appium Pro

make it perfect!

Automating Voice Commands With Siri


     It’s very common with modern mobile devices to rely on virtual “assistants” to get tasks done, whether in a hands-free situation utilizing voice commands, or just to save the trouble of tapping out search queries. On iOS these interactions take place through the Siri interface.

Hey Siri

     How on earth would you test this aspect of your app’s behavior? Ideally you’d be able to have a recording of the particular voice command or phrase used to trigger your app’s Siri integration, which you could then somehow apply to the simulator or device under test. This is not currently possible, outside of rigging up some speakers!

     Fortunately, Appium has recently added a command (as of Appium 1.10.0), that lets you specify the text you want Siri to parse, as if it had been spoken by a person.

The command itself is accessible via the executeScript “mobile” interface:

HashMap<String, String> args = new HashMap<>();
args.put(“text”, “Hey Siri, what’s happening?”);
driver.executeScript(“mobile: siriCommand”, args);

     Essentially, we construct an options hash with our desired text string, and pass it to the siriCommand “mobile” method. We can run this command at any point in our automation, and it will take care of getting to the Siri prompt for us as well (we don’t need to long-hold the home button).

     At this point we can use the typical native automation methods to verify Siri’s response on the screen, tap on action items, etc…

     That’s basically it! There’s not much to it. So let’s have a look at a full example that asks Siri a math question (What’s two plus two?) and verifies the result (notice how the result text shows up as accessibility IDs, which found by looking at the page source).

public void testSiriTalk() {
HashMap<String, String> args = new HashMap<>();
args.put(“text”, “What’s two plus two?”);
driver.executeScript(“mobile: siriCommand“, args);
wait.until(ExpectedConditions.presenceOfElementLocated(MobileBy.AccessibilityId(“2 + 2 =”)));

     You have to use java-client version as 6.1.0 and Appium server version as 1.10.0. Try to use above sample test case to see what exactly automating voice command with Siri.

Reference: Appium Pro

make it perfect !