





















































(For more resources related to this topic, see here.)
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:
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.
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:
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:
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:
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.
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:
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:
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
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.
Further resources on this subject: