Saturday, January 28, 2012

monkeyrunner: testing views properties

There are several questions floating around, like this one in stackoverflow, about how some view properties could be obtained from a monkeyrunner script or putting the question in more general terms:
how a test that verifies some properties can be created using monkeyrunner ?


This is a required feature if we are going to create tests in monkeyrunner otherwise our alternatives to verify some state in the views is limited to visual comparison. These cases were treated in previous articles like:




but now we will be using a logical approach rather than visual comparison. To be able to do it we need a mechanism of obtaining view properties values.
Lastest versions of monkeyrunner provides an extension to MonkeyDevice called EasyMonkeyDevice and this class has methods to get some properties like MonkeyDevice.getText().
This API is not documented so expect changes in the future.
TemperatureConverter, a sample application that has been used in other articles before, will be our application under test. The source code can be obtained from github.


The idea behind this test is, using monkeyrunner to connect to  the device, enter 123 in the Celsius field and expect to find 253.40 in the Fahrenheit field.

#! /usr/bin/env monkeyrunner

import sys
from com.android.monkeyrunner import MonkeyRunner, MonkeyDevice
from com.android.monkeyrunner.easy import EasyMonkeyDevice
from com.android.monkeyrunner.easy import By

# connect to the device
device = MonkeyRunner.waitForConnection()

# start TemperatureConverter
device.startActivity(component="com.example.i2at.tc/.TemperatureConverterActivity")

# use the EasyMonkey API
easyDevice = EasyMonkeyDevice(device)

celsiusId = By.id('id/celsius')
if not celsiusId:
   raise Exception("View with id/celsius not found")

fahrenheitId = By.id('id/fahrenheit')
if not fahrenheitId:
   raise Exception("View with id/fahrenheit not found")

MonkeyRunner.sleep(3)
easyDevice.type(celsiusId, '123')
MonkeyRunner.sleep(3)

celsius = easyDevice.getText(celsiusId)
fahrenheit = easyDevice.getText(fahrenheitId)
expected = '253.40'

if fahrenheit == expected:
   print 'PASS'
else:
   print 'FAIL: expected %s, actual %s' % (expected, fahrenheit)

Unfortunately, it won't work in most of the cases. You are likely to receive this exception:


        java.lang.RuntimeException: java.lang.RuntimeException: No text property on node

I felt frustrated at first, but what the advantage of an Open Source project is other than going to the source code and find out why it's not working.
I dug into the Chimpchat, HierarchyView and ViewServer code and found out that for some reason EasyMonkeyDevice is looking for the text:mText property when in most of the cases it should be only mText.
So here is the patch, that I will be uploading to android soon:

diff --git a/chimpchat/src/com/android/chimpchat/hierarchyviewer/HierarchyViewer.java b/chimpchat/src/com/android/chimpchat/hierarchyviewer/HierarchyViewer.java
index 6ad98ad..6c34d71 100644
--- a/chimpchat/src/com/android/chimpchat/hierarchyviewer/HierarchyViewer.java
+++ b/chimpchat/src/com/android/chimpchat/hierarchyviewer/HierarchyViewer.java
@@ -170,7 +170,11 @@ public class HierarchyViewer {
         }
         ViewNode.Property textProperty = node.namedProperties.get("text:mText");
         if (textProperty == null) {
-            throw new RuntimeException("No text property on node");
+            // dtmilano: give it another chance, ICS ViewServer returns mText
+            textProperty = node.namedProperties.get("mText");
+            if ( textProperty == null ) {
+                throw new RuntimeException("No text property on node");
+            }
         }
         return textProperty.value;
     }
Once this patch is applied and you rebuild monkeyrunner or the entire SDK if you prefer, you will be presented with the expected result: PASS


UPDATE
This patch has been submitted to Android Open Source Project as https://android-review.googlesource.com/31850


UPDATE: July 2012
Android SDK Tools Rev 20 includes the aforementioned patch and now the previous monkeyrunner example works! 

Saturday, January 21, 2012

Automated Android testing using Sikuli

Sikuli is a tool that can supplement you testing toolbox.
It is a visual technology to automate and test graphical user interfaces (GUI) using images (screenshots). The scripts you create with this tool are in the Sikuli Script language, which is a Python (Jython) extension. It also features Sikuli IDE which is an integrated development environment for writing visual scripts with screenshots easily.

There are plenty of examples and tutorials in its web site but most of them are intended for desktop operating systems. As usual here we will be focusing on its Android praxis.


Unlocking the emulator
Out example will be unlocking the emulator screen using some screenshots. That is, instead of guessing or finding out a-priori the coordinates of the touch events that are needed to achieve the goal of unlocking the screen we will use images.
The Sikuli IDE provides the means of obtaining the screenshots to complete the arguments of the specific methods.
For example, if you select the click() method to click over something, you are prompted to take a screenshot of an area of the screen that will be the target and the the IDE shows this thumbnail.
Instead of trying to describe it, it's worth showing you the IDE window to understand what I mean.




The idea is to click on the Android text, just to gain windows focus in case it was lost. The specific method to do this is App.focus("5554") assuming that "5554" appears in the emulator's window title, work on Windows and Linux but it doesn't work on Mac OSX.
Then we search the screen for the image of the lock button, when we find it we touch with the mouse, wait a little, and drag till the position of the unlock dot, where we move up.






Unlocking a pattern lock
The previous example was very illustrative, but sincerely it was a bit simple and could have been done with other tools too.
So, let's get things a bit more complicated as it is the phone locked by a pattern.
As before we take the screenshot of the pattern but this time we double click on it in the IDE to get the Pattern Settings window and there we set the Target Offset to follow the shape of the pattern. This is then identified by a red cross over the screenshot as follows:




When you run this script you can see how the pattern is completed and consequently the phone unlocked.


Pretty simple, right ?
Definitely something you should consider when automating GUI tests.