Frequently Asked Questions

Appium is a mobile UI testing framework supporting cross-platform testing of native, hybrid, and mobile-web apps for iOS and Android. Appium enables you to execute your tests on mobile devices irrespective of the device OS. This is because the framework is basically a wrapper that translates Selenium Webdriver commands into UIAutomation (iOS) or UIAutomator (Android) commands depending on the device type.

To create TestScripts, you can use any language that the Selenium WebDriver dependency is available for. This includes C#, Closure, Java, JavaScript with Node.js, Objective-C, Perl, Python, and Ruby.

No, the server is exactly the same irrespective of the scripting language. This is because the TestScript implements the Selenium WebDriver and communicates with Appium Server via JSON Wire Protocol (a standardized JSON over HTTP protocol).

A great advantage of using Appium is the HTTP communication (see the question above) between TestScript and Appium Server, allowing the server to run on a different machine than the TestScript is run on. This allows us to take care of the Appium server side and maintain the devices in the cloud, while you can run your TestScripts locally from your machine.

Appium TestScripts can either be run as “Live” or uploaded for the cloud to run. This means that you do not need to upload the TestScript along with your app to the Cloud. Instead, you can run the script locally from your own machine, and on receiving a request, the Cloud reserves the requested device and creates an Appium session for it.

There are some best practices to know when writing Appium tests. The test cases of a test suite should re-use the same webdriver between the tests and not recreate a new session every time.

In BitBar Testing, after each test case, with a closed Appium session, the device under test is put offline for automatic cleanup. This will cause the following tests of the test suite to fail.

Instead, a test suite should re-use the first webdriver session from the first test case in all the test cases or add a proper wait time between each test case, poll our API and wait until the device becomes available again. The app can be closed and restarted without having to close the Appium webdriver session:

# close current app
driver.closeApp()
# re-launch the app
driver.launchApp()
# resets the app ~ re-install
driver.resetApp()

Although the TestScripts will be written in the same language and will be almost similar, you would still need to prepare separate TestScripts for iOS and Android, or at least two flavours of the TestScript. This is because of the difference between UI elements on the two platforms. Sometimes, the difference is as subtle as having to use different array indices.

iOS:

buttons = driver.find_elements_by_tag_name('button')
buttons[0].click()

Android:

buttons = driver.find_elements_by_tag_name('button')
buttons[1].click()

Yes, this is practically possible. Since the TestScript communicates live with the Appium server (which is instantiated for a particular device), it cannot communicate with multiple servers simultaneously, or control multiple devices at the same time. You can, however, fire multiple instances of the TestScript, each targeting a separate device. You can find more information on running parallel Appium tests in BitBar Testing.

Yes. On your localhost, this is not possible because Appium uses native Instruments, which is allowed for only one of the devices connected to a Mac at a given time. In BitBar Testing, however, you can run your tests on multiple iOS devices at the same time.

You can check basic configurations at https://appium.bitbar.com/info.

Appium test runs’ screenshots are stored under your device run in the Cloud. If running a client-side test run, screenshots are stored on your local machine where you are executing the Appium test scripts from.

For a working Chrome up to date examples (in Python) in our Github repository, see testdroid_chrome.py. This repository also has examples for native or hybrid mobile app testing using Appium.

There should always be the latest ‘tested’ Appium version running in the Cloud. This means that although there may be a newer release available, it might not yet be available in the Cloud. The current default version is Appium 2.1 for Android testing and Appium 2.0 for iOS testing.

Your test runs are categorized into ‘Project’ and ‘Test-Run’ in the Cloud. A Project typically has multiple Test-Runs in it. The Project name is unique. Running multiple TestScripts using the same Project name puts the Test-Runs under the same Project.

You can upload a new .ipa/.apk application before each Test-Run, but using the same Project for both iOS and Android Test-Runs is not allowed (also see the question above) or recommended.

The maximum size of the app you can upload is 500 MB.

BitBar Testing Appium has the maximum waiting time for a device set to 10 minutes. If there is an ongoing test from another Cloud user, the timeout is very likely to happen. Try again later or with another device.

BitBar Testing has a test run time limit set to 10 minutes. This limit is applicable to Trial Plan users. If you need to run longer tests, please upgrade your subscription.

Check your proxy settings. You should be able to reach http://appium.bitbar.com/info.

Appium projects must be either “Appium Android” or “Appium iOS” by project type in BitBar Testing. The simplest way is to let BitBar Testing create the project for you. This can be done easily by using a new project name in your Appium script.

Examples written in Java, Python, and Ruby are available in BitBar repo at https://github.com/bitbar/bitbar-samples.

Yes. For a C# server side, support through Mono is coming soon.

Currently, we employ Appium 2.1 for Android testing and Appium 2.0 for iOS testing. Android also supports compatibility with various 1.x versions, providing viable alternatives.