Quality Testing

Quality is delighting customers

Robotium---Opensource Android Testing Tool

Getting started

Robotium freely is available online at http://code.google.com/p/robotium/ It calls itself “It’s like Selenium, but for Androidtm

The project includes useful documentation, including a GettingStarted wiki page http://code.google.com/p/robotium/wiki/Getting_Started I was able to create a fresh workspace in Eclipse, create a new project, etc. and run the Example tests within about 15 minutes. The tests seemed to pass correctly on the first attempt, a good sign for an opensource project. I then created a note by hand, to see if the tests could cope with the new circumstances correctly. When I reran the tests they correctly created two new notes, edited them and deleted them without affecting the note I’d created manually. Again, a good sign.

Creating Robotium tests for another project

As an example let’s take the Android Daisy Epub Reader project (one of my projects). In Eclipse, create a new Android Test Project and set the TestTarget to “An existing Android project” of DaisyReader.

In the src folder of the created package, create a new class: I used ExampleTest to get started. At this stage we want to see if we can simply get any JUnit test to run, before we add the Robotium dependencies and other code. Here’s the simplest code I could create:

package com.ader.test;


import android.test.ActivityInstrumentationTestCase2;


import com.ader.DaisyReader;


public class ExampleTest extends ActivityInstrumentationTestCase2<DaisyReader> {


public ExampleTest() {

super("com.ader", DaisyReader.class);



public void testTrue() {

assertTrue("This better pass!", true);






The example code is available at: http://code.google.com/p/android-daisy-epub-reader/source/browse/br...

Critical steps include:

  1. Extending from ActivityInstrumentationTestCase2 and passing in the name of the target class (DaisyReader). Note: The test will still run and pass without the parameterized type.

  2. Creating the constructor that takes no arguments (Eclipse created one with two parameters). If you leave the default constructor, created by Eclipse, you’ll get an error similar the one mentioned in the following section.

The signature of the default constructor is:

public ExampleTest(String pkg, Class<DaisyReader> activityClass)


And the error reported by the test runner will be similar to the following:

junit.framework.AssertionFailedError: Class com.ader.test.ExampleTest has no public constructor TestCase(String name) or TestCase()

at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:164)

at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:151)

at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:425)

at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1520)


At this stage we could simply continue adding Activity Tests, however we’ll start using Robotium for the UI testing.

Adding the dependency on Robotium

In Eclipse we can add the dependency on the robotium-solo jar file (and the javadocs in the parallel jar file). These 2 jar files can be downloaded from the Robotium googlecode site. At the time of writing I’m using version 2.0.2 of both files. The basic setUp() and tearDown() methods were copied from the example. See http://code.google.com/p/android-daisy-epub-reader/source/detail?r=198 for the code.

Correcting mistaken assumptions

When I tried to run the first Robotium test I noticed I’d picked the wrong Activity, I needed to pick HomeScreen, not DaisyReader. I also needed to create an ActivityLauncher. Changes are visible in http://code.google.com/p/android-daisy-epub-reader/source/detail?r=199

Making the test more potent

We’d like to add some power to the initial test using Robotium, to check the number of buttons, and the text on the buttons to ensure at least one has the text ‘Settings’ on it. The related code is available in http://code.google.com/p/android-daisy-epub-reader/source/detail?r=201 Note: I created an AVD (Android Virtual Device) configured with the Norwegian Book Language locale to ensure the test failed when the application uses another language. At the time of writing, German and Norwegian are supported so we could create AVDs for either of these languages and expect the test that looks for the text ‘Settings’ to fail. We will need to see if we can find ways to test localized applications.

Tips and Traps

  • Text Strings may be interpreted as regular expressions. For instance solo.waitForText("Toast\\+"+text) needs to have the \\ passed in order to match the + character in the User-Interface.

Code Coverage

It’s possible to generate code coverage reports for your Robotium Tests if you’re prepared to use the command line and ant scripts. See http://code.google.com/p/robotium/wiki/QuestionsAndAnswers and search for the question and answer on code coverage for the details.

Capabilities and Limitations

Detecting Toasts

Robotium version 2.0.2 is able to detect the contents of a Toast on the screen, older versions such as 1.7.1 seemed to have problems doing so. Detection can use either:

assertTrue(this.solo.waitForText("My Toast Message"));

assertTrue(this.solo.searchText("My Toast Message"));


The Toast message used a duration of Toast.LENGTH_LONG I suspect detecting short durations may be a challenge based on the sleep times used by Robotium internally (see Sleeper.java in the Robotium source).


Here are some thoughts on Robotium which may be worth investigating as part of determining its strengths and limitations.

  • Can Robotium detect ‘Toasts’? If so, how reliably and effectively?

  • How does Robotium cope with starting Activities and crossing the boundary from one Activity to another? We can create some basic test cases to try this out...

  • How should we test multi-lingual applications e.g. with multiple translations? Can we query / detect which language / locale is configured on the device using the Activity Test Case (or Robotium)?

  • Can Robotium interact with labels used for improving Accessibility?

  • How can we run tests when the screen is locked? Currently (r201) the test that checks the buttons are visible fails when the screen is locked or off.





  1. http://wiebe-elsinga.com/blog/?p=300 Which includes source code for a very simple Android application and a Robotium Test for that application. At the time of writing (30 December 2010) the unzipped AndroidTest project needs the build path updating to refer to a local copy of the Robotium Jar. I tested with version 1.7.0 of the JAR file (which was closer to the referenced version than the current version).

  2. http://robotium.googlecode.com/files/RobotiumForBeginners.pdf How to create Robotium Tests for an existing APK file (where you don’t have access to the source code).

  3. http://code.google.com/p/robotium/wiki/RobotiumForPreInstalledApps

  4. http://bitbar.com/blog/54/automated-ui-testing-android-applications... has another well-commented example of using Robotium.



Views: 1306


You need to be a member of Quality Testing to add comments!

Join Quality Testing

Comment by qinggchu on September 2, 2011 at 5:32am
Thanks for your robotium learning material. Hope you can make more examples!

TTWT Magazine





© 2017   Created by Quality Testing.   Powered by

Badges  |  Report an Issue  |  Terms of Service