Facebook EmaiInACirclel
Mobile development

Mobile Automation Made Easy with Robot Framework and Appium

Liviu Avram
Liviu Avram
Scrum Master

I am here with some good news: mobile automation with Robot Framework and Appium will make your team’s life easier. As technology and software become more and more complex, quality assurance departments face greater challenges every day. We are forced to validate our products faster, better and safer.

So, what can you do when the demand is high, and the validation period is short? You start automating.

Automation is nothing but the execution of the same pre-defined steps over and over, as many times as you like, so you don’t have to do it manually.

mobile automation - QA automation with Robot Framework and Appium

Never stop learning! Automation saves time and money. But you need to do it right.

The journey to successful automation starts with the right tools and the right people to do the work. The first problem is that people with validation skills don’t always have programming skills, which are needed for most automation solutions (Java, C#, Python, etc.).

Robot Framework

Robot Framework is a generic automation framework designed for a great number of applications. It can be used for testing apps (web, mobile, desktop) and much more.

The idea behind this framework is that an automation framework must be operating system and application-independent. This means that you can use it to automate applications on Linux, Windows, Mac, etc. and use libraries written in your favorite programming languages, Python or Java.

Test cases are simple text files with “robot” extension. They can be edited in your favorite IDE (Notepad, PyCharm, etc.). Pycharm with robot plugin is great for writing Robot Framework test cases because it offers syntax highlighting and other cool benefits that help you write the cases.

One of the best features of Robot Framework is that it uses a keyword-driven testing approach, so you don’t have to actually “touch” coding. What does this mean?

Here’s a basic example of a Robot Framework test case for WEB, using SeleniumLibrary and Selenium:

*** Settings ***
Documentation     A test suite with a single test for valid login.
Library     SeleniumLibrary
*** Test Cases ***
Valid Login
Open Browser https://www.example.com     chrome
Input Text     xpath://input[@id=”username”]     demo
Input Text     xpath://input[@id=”password”]     mode
Click Element     xpath://button[@type=”submit”]
Wait Until Page Contains    Welcome to your account!
[Teardown]    Close Browser


In this example we are using keywords provided inside SeleniumLibrary to create a WEB test case that will:

  • Open Chrome browser to the desired page (https://example.com)
  • Input the username “demo” inside the input field with the provided XPath
  • Input the password “mode” inside the input field with the provided XPath
  • Click the submit sign-in button
  • Wait until the welcome message is displayed, so the user knows the sign-in was successful and he is redirected to the proper page.

So, we are using keywords already declared inside the library, like “Open Browser”, “Input Text”, “Click Button” and whatever comes after them are called arguments.

As you can see, we are not touching any programming language and keywords are written so that they are self-explanatory. This is the keyword-driven method. Of course, there are many libraries for many testing applications. Available libraries are listed on the website, here.

The beauty of this is that you can use existing library keywords to create user-defined keywords. Example:

Test Login With Demo User
Input Text     xpath://input[@id=”username”]     demo
Input Text     xpath://input[@id=”password”]     mode
Click Element     xpath://button[@type=”submit”]
Wait Until Page Contains     Welcome to your account!


Because we have written our own keyword, we can call it inside the test so that the final result looks like this:

*** Settings ***
Documentation     A test suite with a single test for valid login.
Library     SeleniumLibrary
*** Keywords ***
Test Login With Demo User
Input Text     xpath://input[@id=”username”]     demo
Input Text     xpath://input[@id=”password”]     mode
Click Element     xpath://button[@type=”submit”]
Wait Until Page Contains     Welcome to your account!
*** Test Cases ***
Valid Login
Open Browser  https://www.example.com     chrome
Test Login With Demo User
[Teardown]     Close Browser


Custom keywords can be declared inside resource files so they can be called in all test cases where they are needed. More examples can be found inside the “Examples” section of the official website, here.

As we said before, Robot Framework is open-source. The project is hosted on GitHub and it has a big community of developers working around the clock to keep it updated, add new functionalities and solve bugs.

If this section convinces you, you can browse the documentation section of the website, where you can find installation instructions, user guides, demos, videos and much more. Getting started with Robot Framework is easy.

To automate mobile applications with Robot Framework, we need one other tool. This will interact as the “translator” between Robot Framework and the mobile device. This is where Appium comes in.


This is another open-source tool for automating apps on iOS, Android and Windows. It can be used to automate Native apps (written using the iOS, Android, or Windows SDKs), Mobile web apps (web apps accessed using a mobile browser) and Hybrid apps (apps that have a wrapper around a “webview” – a native control that enables interaction with web content).

It is very important to note that Appium is “cross-platform”. This means you can create test cases against multiple platforms (iOS, Android, Windows) using the same API.

Appium was designed to meet mobile automation needs according to a philosophy outlined by the following four tenets:

  1. You shouldn’t have to recompile your app or modify it in any way in order to automate it.
    You can automate the application under test without having to create a special type of build for it or install it on the OS with special conditions. In simple terms, you just need to install the application on the device as you might normally, inspect the elements and start automating it.
  2. You shouldn’t be locked into a specific language or framework to write and run your tests.
    The job of the Appium client is to provide data to the Appium server who sends it to the application under test. No matter the source of the Appium client language (Python, Java, C#), requests are transformed into JSON format by Appium server and sent to the application (JSON Wire Protocol) over http.
  3. A mobile automation framework shouldn’t reinvent the wheel when it comes to automation APIs.
  4. mobile automation - appium

    Instead of developing their own webdrivers in order to communicate with the application under test, Appium uses the platform’s own webdriver and calls it directly in order to communicate and do actions on the device. For Android it uses the native webdrivers called UIAutomator and UIAutomator2, for iOS above version 9.0 it uses XCUITest and for Windows it uses WinApp driver.

  5. A mobile automation framework should be open source, in spirit and practice as well as in name!
    Appium is also hosted on GitHub and it has a great community that makes sure standards remain high and users don’t get into trouble when OS or other third-party apps are updated.
    Installation instructions and further documentation can be found on Appium official website.
    Also, you will need to install Java and Android sdk-tools in order to correctly run tests on Android devices.

Inspecting Mobile Interface Elements

To automate a mobile application, we must first be able to inspect elements on the interface. This means opening the application on the device and using an inspector. Luckily, Appium has a built-in tool that helps get the job done.

mobile automation - appium - inspect elements

For Android, we can also use “uiautomatorviewer” which is part of ADB tools. Here’s an example of how the Android mobile interface looks under the inspector.

android mobile interface

UI elements can be declared as XPath expressions, id or any other method available. Let’s take a closer look at this interface and see how they can be declared.

XPath examples for this element:

//android.widget.TextView[@text=‘Liviu Avram Test1’]

//android.widget.TextView[contains(@resource-id,’nameTextView’) and @text=‘Liviu Avram Test1’]

//android.widget.TextView[@text=‘Liviu Avram Test1’ and @enabled=‘true’]

As we can see, each element has a class, a resource-id and other attributes that help us correctly identify it as unique.

In order to inspect iOS interface elements, the Appium inspector is used. Its interface is similar to that of Android and the elements are also identified by class, id and other attributes.

IMPORTANT NOTICE: Android tests can be run on Windows, Linux or MacOS, while iOS tests cand be run only on MacOS. The reason for this is that Android tests rely on Android Studio and SDK tools which can be installed and run on all the above declared OS, while iOS tests rely on xCode, developed by Apple and only available for MacOS.

Mobile Automation with Robot Framework and Appium

Now that we understand how Robot Framework works and how Appium works, it’s time to put them together and create our test cases.

First, we need to start an Appium server. This contains a link and a port, used to interact with the device. Each Appium instance should have its own port so we need to create as many server instances as we have devices. Starting an Appium server can either be started using Appium Desktop or command line.

Example for starting Appium using the command line:

appium –port 4725

appium –port 4726

In this example, we have started two Appium server instances on ports 4725 and port 4726. These will be called by the Appium client to send commands to the tested device. The default port is 4723. There are other attributes besides ports that can be used when starting a server. The full list is available here.

As we said before, to automate something, we must first import a library in the Robot Framework. For Appium, the library is called AppiumLibrary and its documentation can be found here.

Used Keywords are similar to those used by SeleniumLibrary so at this point you can have an idea about how easy it is to switch and learn how to automate on different platforms.

mobile automation - developer options

To execute a test case on the mobile device (Android), we first connect it to the PC with the USB cable and activate the “USB debugging” option from the “Developer options” menu, as shown.

Now that we started an Appium server instance and we connected our mobile device, let’s see how a mobile test case looks in Robot Framework to open a certain application on the mobile device (Android):

*** Settings ***
Library     AppiumLibrary
*** Test Cases ***
Open Application On Android
Open Application     http://localhost:4725     udid=< deviceid > platformName=Android     deviceName=AndroidDevice     app=com.example.com
appActivity= com.example.com.MainActivity
[Teardown]     Close Application


In this script, we are importing the “AppiumLibrary” inside the “Settings” section of the script so that we can use all the Keywords that belong to this library.

Then, in the “Test Cases” section, we must first declare a name for our test case so it will appear on the execution log.

The most important command to start the automatic test is the “Open Application” keyword so that Appium can start interacting with the device. In this example, Robot Framework acts like the Appium client and it sends the code to the Appium server, which in the end transforms data into JSON and sends it to the device.

The “Open Application” command must be used along with minimum arguments, as shown above. They are:

  • Appium Server instance URL (mandatory): http://localhost:4725
  • UDID of the device under test so that Appium knows which device to connect to: udid=< deviceid >. This device id can be obtained by running the following command inside a terminal: adb devices
  • Name of the platform under test: platformName=Android
  • Name of the device under test: deviceName=AndroidDevice (this name is chosen by the user and it’s given only as a reference. It doesn’t have to match the actual device name set in the settings section of the OS)
  • Application package, as seen inside the interface inspector, corresponding to the “package” attribute
  • Application activity required for Appium to know which page of the application to open. In most of the cases this is declared as the main activity but a list of all activities available for a certain application can be inspected using an Android application called Apk Info, available on Google Play. For iOS devices we only need the bundleid of the application

Finally, in order to run the test case, we use the following command inside a terminal:

robot testcasename.robot

If Robot Framework and Appium are correctly installed, “robot” will be recognized as an internal command of the OS and the testcase will run smoothly.

test case log - mobile automation

In the end, Robot Framework creates a beautiful log with the execution summary, as well as an execution report. Both are in html format so they can be open and inspected inside a browser.

test case report - mobile automation

With all this powerful information in hand, I wish you happy (mobile automation) testing!

If you want to learn more about Robot Framework and mobile automation, feel free to check my YouTube channel where I create a complete Robot Framework tutorial from scratch and offer automation tips, tricks and more.


Has this article sparked your interest for mobile automation? If you have any questions regarding this topic, please post a comment! I’m happy to help.


Read also:

Editor’s note: This post was originally published in October 2019 and has been updated for accuracy and comprehensiveness.


Leave a Reply

Your email address will not be published. Required fields are marked *