Automating Android apps with Robot Framework and Appium

Andy Kelk

Automating Android apps with Robot Framework and Appium

As part of the DevFoundry event this week, I proposed to do some basic test automation of an app using Robot Framework, Appium and AWS Device Farm. Within the team we use Robot Framework as a keyword-driven tool for functional testing to allow non-coders to create executable test cases. But we’ve not yet hooked it up for mobile app testing.

Reality bites

My first confrontation with reality came when I actually read the product documentation for Device Farm; unfortunately for Device Farm to work, you need to use TestNG, JUnit or Python and bundle your tests up and upload them – Robot isn’t supported. So I readjusted my plan to just get Robot + Appium + a local Android emulator going. I decided to use the AFL Supercoach app for my project.

Getting going

There’s a lot of prerequisites to install to get the various tools I wanted to use going – python, node and java being the main ones. I had decided to use an old Centos 7 virtual machine I had lying around on my Macbook to do my development. The first struggle I had was getting npm to install appium as the node version distributed with Centos was too old for appium. After a quick diversion via nvm (I struggled to get global installation permissions working), I followed this guide to get linuxbrew working and installed node, npm and then appium.

Yak, meet razor

It was then that I got further and further from solving my problem. My decision to do everything on a virtual machine started to become a barrier to progress. My 8Gb virtual disk proved to be far too small to get everything I needed installed so followed an hour-long diversion of resizing the disk, resizing the partition on the disk (hint: the gparted ISO seems to need EFI enabled on Virtualbox to boot!) and then resizing the logical volumes. By this point I’d almost lost sight of the problem I was originally trying to solve.

Deep breath

Back in the land of automation testing, I now challenged myself to get an apk loaded onto the emulator and have Robot take a screenshot. Simple, right? The first step is to get the Android SDK installed. Getting the SDK is easy; I wanted to run the emulator as a headless application so I followed this guide (from the section “Setting up a headless installation of Android”). I chose to use the latest and greatest Android version. All seemed to be going well – I installed the excellent Appium library for Robot and wrote a simple test to create a snapshot:

*** Settings ***
Library	AppiumLibrary

*** Variables ***
${REMOTE_URL}	http://localhost:4723/wd/hub

*** Keywords ***
TestStart
    Open Application	${REMOTE_URL}	deviceName=192.168.56.101:4723	app=${CURDIR}/app-afl-release.apk	automationName=appium	appActivity=com.newscorp.supercoach.SplashScreenActivity	appPackage=com.vapormedia.virtualsports.newsafl
    Create Page Snapshot

*** Test Cases ***
Snapshot
    TestStart

On running virtual machines in virtual machines

This is where the VM decision really bit me. It seems that running an emulator inside a virtual machine is slow. Who knew? Slow enough that I couldn’t even upload an apk to the emulator before it timed out. Rather than ripping out everything I’d done to date and running it all natively on my Macbook, I decided to just move the emulator to the Macbook and continue to run appium and robot on the virtual machine. This involved setting up an SSH tunnel from the guest machine (Centos) to the host (OSX). This is pretty simple: activate the SSH server on the Macbook, setting up the emulator on the Mac (same process as on linux) and create an SSH session from the guest machine to the host with local port forwarding:

$ ssh -L 5555:127.0.0.1:5555 -L5554:127.0.0.1:5554 192.168.56.1

Waiting… and waiting…

While setting up the emulator on OSX, I decided to downgrade to an older Android version in the hope of it running a little bit faster. I settled on API version 14 (Android 4.0.0). Except that the Supercoach app requires a minimum API version of 16. Minor setback, on we go.

I now got as far as having the apk deployed onto the emulator, started and I tried to get it to wait for the login screen to appear (it starts with a splash screen). Using the “Wait Until Page Contains Element” keyword seemed like what I wanted. But how to identify which element I was waiting for? Using IDs seemed like the right way to go. Except I couldn’t figure out the right format for the IDs. I got hold of the source code, I tried as many permutations as I could think of and yet the test would always timeout and not recognise the element. I even tried using the UiAutomatorViewer to discover the element IDs. For some reason, even there I couldn’t see any IDs. Stalemate.

The benefits of sleep

That was the end of day 1 and I was at an impasse. Roll forward a few hours of good sleep and I was back at the keyboard to tackle the problem again. It was then that I discovered that upgrading the Android API version would solve my problem. Resource IDs only appeared once I upgraded to API version 19 (Android 4.4.2). Once I discovered that, the rest fell into place.

My final proof-of-concept test script looks something like this:

** Settings ***
Library	AppiumLibrary

*** Variables ***
${REMOTE_URL}	http://localhost:4723/wd/hub

*** Keywords ***
TestStart
    Open Application	${REMOTE_URL}	deviceName=192.168.56.101:4723	app=${CURDIR}/app-afl-release.apk	automationName=appium	appActivity=com.newscorp.supercoach.SplashScreenActivity	appPackage=com.vapormedia.virtualsports.newsafl

*** Test Cases ***
Login Successfully
    TestStart
    Wait Until Page Contains Element	id=com.vapormedia.virtualsports.newsafl:id/email	timeout=60
    Click Element	id=com.vapormedia.virtualsports.newsafl:id/email
    Input Text	id=com.vapormedia.virtualsports.newsafl:id/email	[email protected]
    Click Element	id=com.vapormedia.virtualsports.newsafl:id/password
    Input Password	id=com.vapormedia.virtualsports.newsafl:id/password	mypassword
    Press Keycode	66
    Hide Keyboard
    Wait Until Page Does Not Contain Element	id=com.vapormedia.virtualsports.newsafl:id/email_sign_in_button	timeout=60
    Capture Page Screenshot	logged-in.png

Lessons learned

So to summarise:

Don’t try and run the Android emulator on a Virtual Machine
Running later Android versions may solve unexpected behaviour
Emulators are slow. Really slow

Posted on May 21, 2016 by Andy Kelk

Andy Kelk