Appium integration
The integration with Appium enables you to run Appium scripts utilizing the features of OpenText Functional Testing Lab.
In this topic:
- Prepare your environment
- Prepare your Appium test
- Appium script execution
- Use Appium with SSL
- Appium setup code snippets
- Common Appium API calls
- Report test status to the lab
- Retrieve Appium logs
- Parallel tests
Prepare your environment
To prepare your environment to run an automated Appium test, you need to configure your working environment such as Visual Studio or Eclipse to recognize the Appium project.
Prepare your Appium test
To prepare your Appium test to run on OpenText Functional Testing Lab:
-
In the code that starts the session, replace the Appium server URL and port with the URL and port of OpenText Functional Testing Lab using the following format (see below for an example):
driver = new AndroidDriver(new URL("http://<my OpenText Functional Testing Lab Server>:<port>/wd/hub"), capabilities);
driver = new IOSDriver(new URL("http://<my OpenText Functional Testing Lab Server>:<port>/wd/hub"), capabilities);
-
Make your apps available for the test by uploading them to OpenText Functional Testing Lab. For details, see Manage apps.
Note: You do not need a Mac machine to install apps on an iOS device.
Appium script execution
The following guidelines should be considered when running an Appium test:
-
Safari Driver is not supported on Linux and Windows.
-
When running your Appium tests through OpenText Functional Testing Lab, you can indicate the method of automation to use during script execution.
OS Details iOS OpenText Functional Testing Lab enables you to run tests on iOS devices without requiring a Mac machine. The automation method used for iOS is XCUITest. Android 8 & higher UiAutomator2 is the default automation engine. The uiautomator2 driver uses Google's UiAutomator2 technology to allow automation on a device or emulator. To overwrite the default and use UiAutomator1, set the automationName Appium capability to "android".
Use Appium with SSL
To work with Appium and OpenText Functional Testing Lab using SSL, the Appium client needs to trust the OpenText Functional Testing Lab certificate.
If the SSL certificate is not signed by a well known certification authority, perform the following:
Appium client | Procedure |
---|---|
Appium Inspector |
|
Other |
Export the OpenText Functional Testing Lab certificate and configure the Appium client to trust it (recommended). Alternatively, configure the client to ignore the SSL warning. For details on exporting certificates, see SSL and certificates. |
Appium setup code snippets
The following code snippets show sample setups for Android native apps, Chrome, iOS native apps, and iOS Safari. The lines in bold are mandatory.
For a list of the common capabilities and their support in OpenText Functional Testing Lab, see Appium Capabilities.
Important: These code snippets use Java-Client v7.x. If you plan to use v8 or later, see the official Java-Client migration guide on github. For additional code samples, see the UFTM github repository.
For additional code samples see Appium code example - Java and Appium simulations.
Common Appium API calls
Use the following Appium API calls to manage your apps.
Kill application
The Kill API call stops the application. It does not simply minimize the app—it terminates the process. The script name is mc:application:kill, and must use one of the following arguments:
-
appPackage (Android) or bundleId (iOS)
-
id or uuid as used in the REST API reference - Apps Install / Uninstall.
Capability | Details |
---|---|
appPackage | Android only. The package name that identifies the app, displayed as Package ID in the app details card. For example, com.Advantage.aShopping |
bundleId | iOS only. A unique identifier, the Bundle ID of the app, displayed as Package ID in the app details card. For example, com.mf.iShopping |
id | The application identifier (string). For example:
com.mf.iShopping. |
uuid | Universally unique identifier (UUID). This is the unique application specific id assigned by OpenText Functional Testing Lab. For example, "bf441f2b-3f16-4bb5-950d-4e3eaf2efffb". |
The following sample code terminates the Android Advantage app:
Map<String, Object> params = new HashMap<String, Object>();
params.put("appPackage", "com.Advantage.aShopping");
appiumDriver.executeScript("mc:application:kill", params);
The line beginning with "params.put" can be replaced with any of the following options:
-
params.put("bundleId", "com.mf.iShopping");
-
params.put("uuid", "bf441f2b-3f16-4bb5-950d-4e3eaf2efffb");
-
params.put("id", "com.Advantage.aShopping");
For additional code samples see Appium code example - Java and Appium simulations.
Network virtualization capabilities
Refer to the Network Virtualization help center for examples on how to add network virtualization capabilities within OpenText Functional Testing Lab.
Report test status to the lab
OpenText Core SDP only
You can report if a test passed or failed from your Appium or Selenium script. You can then view this in the Results tab of the lab. For more details, see Test results.
To report test status from your Appium/ Selenium test, define a map (Java) or dictionary (C#) with the attributes status and comment. Use the executeScript API to set the status and comments during testing. Comments can be information related to the test failure, for example, the test execution message.
Java example
Map<String, String> status = new HashMap<>();
status.put("status", status); //status can be "Passed" or "Failed"
status.put("comment", comment); //comments can be information relating to the failure, for example, the execution message.
wd.executeScript("FTLab:status", status);
C# example
Dictionary<string, string> statusmap = new Dictionary<string, string>();
statusmap.Add("status", status); //status can be "Passed" or "Failed"
statusmap.Add("comment", comment); //comments can be information relating to the failure, for example, the execution message.
driver.ExecuteScript("FTLab:status", statusmap);
Note: When create Android/iOS driver fails, a status of Not available is sent to the lab.
Retrieve Appium logs
A log file is generated during the execution of your Appium tests.
To retrieve the log, use the mc-wd:downloadLogs script and specify the encoding.
When the connector receives this command, logs are retrieved for all sessions in the current Appium process. Attach the string to the response body.
The Appium user's test code uses the string from the response body and processes it accordingly.
For example:
HashMap<String, String> encoding= new HashMap<String, String>();
encoding.put("encoding", "UTF-8");
String logFileContents = (String) wd.executeScript("mc-wd: downloadLogs", encoding);
For additional code samples see Appium code example - Java and Appium simulations.
Parallel tests
You can run parallel Appium and Selenium tests on OpenText Functional Testing Lab.
You can do this through coding, or using your CI (Continuous Integration) tools such as Jenkins. For an example of how to run parallel tests in Jenkins, see the Parallel Test Executor plugin in the Jenkins Wiki.
See also: