9 min read

(For more resources related to this topic, see here.)

Robotium framework

Robotium is an open source automation testing framework that is used to write a robust and powerful black box for Android applications (the emphasis is mostly on black box test cases). It fully supports testing for native and hybrid applications. Native apps are live on the device, that is, designed for a specific platform and can be installed from the Google Play Store, whereas Hybrid apps are partly native and partly web apps. These can also be installed from the app store, but require the HTML to be rendered in the browser.

Robotium is mostly used to automate UI test cases and internally uses run-time binding to Graphical User Interface (GUI) components.

Robotium is released under the Apache License 2.0. It is free to download and can be easily used by individuals and enterprises and is built on Java and JUnit 3. It will be more appropriate to call Robotium an extension of the Android Test Unit Framework, available at http://developer.android.com/tools/testing/testing_android.html. Robotium can also work without the application, under the test’s source code.

The test cases written using Robotium can either be executed on the Android Emulator (Android Virtual Device (AVD))—we will see how to create an AVD during installation in the following section—or on a real Android device. Developers can write function, system, and acceptance test scenarios across multiple activities.

It is currently the world’s leading Automation Testing Framework, and many open source developers are contributing to introduce more and more exciting features in subsequent releases. The following screenshot is of the git repository website for the Robotium project:

As Robotium is an open source project, anyone can contribute for the purpose of development and help in enhancing the framework with many more features. The Robotium source code is maintained at GitHub and can be accessed using the following link:

https://github.com/jayway/robotium

You just need to fork the project. Make all your changes in a clone project and click on Pull Request on your repository to tell core team members which changes to bring in. If you are new to the git environment, you can refer to the GitHub tutorial at the following link:

https://help.github.com/

Robotium is like Selenium but for Android. This project was started in January 2010 by Renas Reda. He is the founder and main developer for Robotium. The project initiated with v1.0 and continues to be followed up with new releases due to new requirements. It has support for Android features such as activities, toasts, menus, context menus, web views, and remote controls.

Let’s see most of the Robotium features and benefits for Android test case developers.

Features and benefits

Automated testing using Robotium has many features and benefits. The triangularization workflow diagram between the user, Robotium, and the Android device clearly explains use cases between them:

The features and benefits of Robotium are as follows:

  • Robotium helps us to quickly write powerful test cases with minimal knowledge of the application under test.
  • Robotium offers APIs to directly interact with UI controls within the Android application such as EditText, TextView, and Button.
  • Robotium officially supports Android 1.6 and above versions.
  • The Android platform is not modified by Robotium.
  • The Robotium test can also be executed using command prompt.
  • Robotium can be integrated smoothly with Maven or Ant. This helps to add Robotium to your project’s build automation process.
  • Screenshots can be captured in Robotium (an example screenshot is shown as follows):

  • The test application project and the application project run on the same JVM, that is, Dalvik Virtual Machine (DVM).
  • It’s possible to run Robotium without a source code.
  • Robotium can work with other code coverage measurement tools, such as Cobertura and Emma.
  • Robotium can detect the messages that are shown on the screen (Toasts).
  • Robotium supports Android features such as activities, menu, and context menu.
  • Robotium automated tests can be implemented quickly. Robotium is built on JUnit, because of which it inherits all JUnit’s features. The Robotium framework automatically handles multiple activities in an Android application.
  • Robotium test cases are prominently readable, in comparison to standard instrumentation tests.
  • Scrolling activity is automatically handled by the Robotium framework.
  • Recent versions of Robotium support hybrid applications. Hybrid applications use WebViews to present the HTML and JavaScript files in full screen, using the native browser rendering engine.

API set

Web support has been added to the Robotium framework since Robotium 4.0 released. Robotium has full support for hybrid applications. There are some key differences between native and hybrid applications. Let’s go through them one by one, as follows:

Native Application

Hybrid Application

Platform dependent

Cross platform

Run on the device’s internal software and hardware

Built using HTML5 and JavaScript and wrapped inside a thin native container that provides access to native platform features

Need more developers to build apps on different platforms and learning time is more

Save development cost and time

Excellent performance

Less performance

The native and hybrid applications are shown as follows:

Let’s see some of the existing methods in Robotium that support access to web content. They are as follows:

  • searchText (String text)
  • scrollUp/Down ()
  • clickOnText (String text)
  • takeScreenshot ()
  • waitForText (String text)

In the methods specifically added for web support, the class By is used as a parameter. It is an abstract class used as a conjunction with the web methods. These methods are used to select different WebElements by their properties, such as ID and name.

The element used in a web view is referred to as a WebElement. It is similar to the WebDriver implemented in Selenium. The following table lists all the methods inside the class By:

Method

Description

className (String className)

Select a WebElement by its class name

cssSelector (String selectors)

Select a WebElement by its CSS selector

getValue ()

Return the value

id (String id)

Select a WebElement by its id

name (String name)

Select a WebElement by its name

tagName (String tagName)

Select a WebElement by its tag name

textContent (String textContent)

Select a WebElement by its text content

xpath (String xpath)

Select a WebElement by its xpath

Some of the important methods in the Robotium framework, that aim at direct communication with web content in Android applications, are listed as follows:

  • clickOnWebElement(By by): It clicks on the WebElement matching the specified By class object.
  • waitForWebElement(By by): It waits for the WebElement matching the specified By class object.
  • getWebElement(By by, int index): It returns a WebElement matching the specified By class object and index.
  • enterTextInWebElement(By by, String text): It enters the text in a WebElement matching the specified By class object.
  • typeTextInWebElement(By by): It types the text in a WebElement matching the specified By class object. In this method, the program actually types the text letter by letter using the keyboard, whereas enterTextInWebElement directly enters the text in the particular.
  • clearTextInWebElement(By by): It clears the text in a WebElement matching the specified By class object.
  • getCurrentWebElements(By by): It returns the ArrayList of WebElements displayed in the active web view matching the specified By class object.

Before actually looking into the hybrid test example, let’s gain more information about WebViews.

You can get an instance of WebView using the Solo class as follows:

WebView wb = solo.getCurrentViews(WebView.class).get(0);

Now that you have control of WebView, you can inject your JavaScript code as follows:

Wb.loadUrl("<JavaScript>");

This is very powerful, as we can call every function on the current page; thus, it helps automation.

Robotium Remote Control using SAFS

SAFS tests are not wrapped up as JUnit tests and the SAFS Remote Control of Robotium uses an implementation that is NOT JUnit based. Also, there is no technical requirement for a JUnit on the Remote-Control side of the test.

The test setup and deployment of the automation of the target app can be achieved using the SDK tools. These tools are used as part of the test runtime such as adb and aapt. The existing packaging tools can be used to repackage a compiled Robotium test with an alternate AndroidManifest.xml file, which can change the target application at runtime.

SAFS is a general-purpose, data-driven framework. The only thing that should be provided by the user is the target package name or APK path arguments. The test will extract and redeploy the modified packages automatically and then launch the actual test.

Traditional JUnit/Robotium users might not have, or see the need for, this general-purpose nature, but that is likely because it was necessary for the previous Android tests to be JUnit tests. It is required for the test to target one specific application. The Remote Control application is application specific. That’s why the test app with the Remote Control installed in the device no longer needs to be an application.

The Remote Control in Robotium means there are two test applications to build for any given test. They are as follows:

  • Traditional on-device Robotium/JUnit test app
  • Remote Control app

These two build projects have entirely different dependencies and build scripts.

The on-device test app has the traditional Robotium/Android/JUnit dependencies and build scripts, while the Remote Control app only has dependencies on the TCP sockets for communications and Robotium Remote Control API.

The implementation for the remote-controlled Robotium can be done in the following two pieces:

  • On Device: ActivityInstrumentationTestCase2.setup() is initialized when Robotium’s Solo class object is to be used for the RobotiumTestRunner (RTR). The RTR has a Remote Control Listener and routes remote control calls and data to the appropriate Solo class methods and returns any results, as needed, to the Remote Controller. The on-device implementation may exploit test-result asserts if that is desirable.
  • Remote Controller: The RemoteSolo API duplicates the traditional Solo API, but its implementation largely pushes the data through the Remote Control to the RTR, and then receives results from the Remote Controller. The Remote Control implementation may exploit any number of options for asserting, handling, or otherwise reporting or tracking the test results for each call.

    As you can see, the Remote-Control side only requires a RemoteSolo API without any specific JUnit context. It can be wrapped in a JUnit context if the tester desires it, but it is not necessary to be in a JUnit context.

The sample code and installation of Robotium Remote Control can be accessed in the following link:

http://code.google.com/p/robotium/wiki/RemoteControl

Summary

Thus this article introduced us to the Robotium framework, its different features, its benefits in the world of automated testing, the API set of the Robotium Framework, and how to implement the Robotium Remote Control using SAFS.

Resources for Article:

Further resources on this subject:

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here