Automating Android Native Apps testing using Android Native Driver

One of the most useful open source tools for web testing to have emerged has been WebDriver. This is a topic on its own and warrants a blog entry by itself. In summary, the tool allows the tester to test against actual browsers eg. Chrome, IE, Firefox. The WebDriver team then extended the tool to allow for testing against browsers on iPhone simulators and Android emulators as well.

Now they have extended it to allow for automating tests for Native Apps via a similar interface. This is what the Native Driver group is trying to achieve (see Unlike Robotium, where the “Solo” object is the main player, testers familiar with WebDriver will find the API for Android Native Driver much closer to what they’re used to in WebDriver.

Another point of departure from Robotium is that for Native Driver, some server code resides on the app itself – making it a HTTP server taking in JSON commands. This is similar to Frank – an automation tool used for iOS native app testing (and subject of another blog post). This is particularly useful if you want to separate the TestRunner from the emulated app.

Installing Eclipse and Android SDK

As with Robotium, a major pre-requisite for working with Robotium is installing Eclipse and the Android SDK. See Setting up your Android Native App Test Environment.

Installing and running the Android Native Driver Test Project

  1. The Android Native Driver site has steps to download and compile the library – see
  2. You will need to check out the code on SVN, and compile using “ant”. Alternatively, you could import the code as an Eclipse project and build via the Project->Build option in the Eclipse IDE.
  3. Follow the instructions on the Twiki to install the “samplelayouts” test app and use the “adb” tool to install the samplelayout app into the Android emulator. I recommend this before testing using device.
  4. Follow the instructions on the Twiki to prepare the Android emulator to receive requests
  5. Follow the instructions on the Twiki to run the tests

Like Robotium, you should see the Android emulator pop up and (after some time) the simplelayouts app “going through the motions” of the tests.

Deconstructing the test code

Let’s take a look at the class which basically extends the standard JUnit TestCase class.
Like most WebDriver test code, the “driver” object is the key. For this case, a AndroidNativeDriver object is used.

Next comes the standard set up and tear down methods:

protected void setUp() {
driver = getDriver();

protected void tearDown() {

Notice that the setUp method makes a getDriver call. This is calls the getDriver method which uses a factory method to build a AndroidNativeDriver object.

protected AndroidNativeDriver getDriver() {
return new AndroidNativeDriverBuilder()

Next comes the call to activate the appropriate Activity class in the app:

private void startSpinnersActivity() {
driver.startActivity("" +

This method is used in the test methods to kick off the Activity to be tested. An example is the testFindByText_noResult method. Notice that the first line is a call to startSpinnersActivity().

Now we take a look at the meat of the code found in testFindByText_noResult, testFindByText_resultFromSpinnerPopup, testFindByText_elementInitiallyInvisible, testFindByPartialText_multipleResultsFromSpinnerPopup.

WebDriver users will no doubt find this very familiar. This call is to find a UI element with id=planet_spinner and click on it. How do we identify the id? To do so, on Eclipse, navigate to the simplelayouts project. Under res (or resources), select “layout”. There you will find the spinner.xml. Click on that and it will show up on Eclipse. There notice that there’s a"+id/planet_spinner".

This basically searches for a UI element with label “Earth”. This is to test that the text exists.

try {
// Search for something that should not appear. Pluto is not a planet.
fail("Should have thrown a NoSuchElementException.");
} catch (NoSuchElementException exception) {
// Expected exception.

This try block is to test that the text does not exist.

AndroidManifest.xml and Preparing your app for Android Native Driver

There are some configs that need modification in the AndroidManifest.xml file. These can be found here: Basically there needs to be a <code>instrumentation</code> section and several <code>uses-permission</code> sections to allow for it to be tested by NativeDriver.

The wiki page also details the steps needed to add the client and server standalone jars (server for the app to be tested and client for the NativeDriver code.

Additional Information


Filed under Android, Native App, QA, Testing

4 responses to “Automating Android Native Apps testing using Android Native Driver

  1. Nisse

    “Like Robotium, there are some configs that need modification in the AndroidManifest.xml file. Several uses-permission sections to allow for it to be tested by NativeDriver.”

    That is not true. Robotium does not require any changes to the AndroidManifest.xml of the application under test.

  2. Hi, How far have you got with this? I’m having problems accessing native elements. I’m trying to get a WebView to test it’s url. but at runtime i get an error. “java.lang.NoClassDefFoundError: android/webkit/WebView ”

    WebView webView = (WebView)driver.findAndroidNativeElements(“myWebview”));

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s