For me, the most important aspects of Robotium is first most that it is stable and that one can trust the results. Secondly, that it is easy enough to use for non-technical users. A user should not need to be technically inclined to use Robotium or it would have lost its purpose in helping a large user group who know how to write good test cases but lack a bit in the technical area.

Robotium uses a system of waiting for a component before trying to interact with it. The problem with UI testing compared to normal unit tests is that the UI is slow. When writing normal unit tests, the code gets executed in a fast pace by the CPU. That is not the case with the UI. Therefore, UI test cases that are developed without any kind of wait mechanism will sooner or later run into issues. With Robotium 3.0, two completely new waitFor methods have been implemented:

waitForView(View view, int timeout, boolean scroll)

The various waitFor() methods available in Robotium are used automatically by the, is, get, click, search, scroll and assert methods. However it is always recommended to add additional waitFor calls in your test cases if they will be running on a slow computer or a slow hudson slave. An example of a waitFor method in Robotium that can be beneficial to use is waitForActivity(String name). The purpose of it is to wait for a certain activity before continuing with the execution. To find out which activity that is active at the moment, you can always look at the log by using adb logcat.

One major change in Robotium 3.0 is that finalize() is now replaced with finishOpenedActivities(). Anyone that has used finalize() before in their tearDown() to close the activities that have been started will need to update their test cases.

If you have not tried Robotium before, I recommend you to first read the Question and Answers wiki page.

For tutorials please go to the Robotium Tutorials wiki page.

To download the javadoc and the latest release of Robotium please go to the Downloads page.

I hope you will enjoy the new and improved Robotium!

I soon came to understand that I would not be able to take advantage of all the wonderful possibilities that instrumentation offers. The reason for that is quite simple; the application that we are in the process of developing is not only extensive but also complicated with multiple activities, self-defined intents, and hundreds of views that also include scrollable lists. It would not make sense for me to spend a month writing one single test case that would only take 20 seconds to test manually. That is how Robotium was born. I needed a test framework that would help me write good and powerful test cases that emulated real users. The test case should be able to do what a real user does: click on anything that is clickable, look for irregularities, automatically move from activity to activity, etc. More importantly, I should not have to spend more than 10 minutes writing a test case that involves more then one activity.

With the help of Robotium a test case spanning over multiple activities could look like this:

public void testTextIsSaved() throws Exception {
   solo.clickOnText("Other");
   solo.clickOnButton("Edit");
   assertTrue(solo.searchText("Edit Window"));
   solo.enterText(0, "Some text for testing purposes")
   solo.clickOnButton("Save");
   assertTrue(solo.searchText("Changes have been made successfully"));
   solo.clickOnButton("Ok");
   assertTrue(solo.searchText("Some text for testing purposes"));
}

As you can see, I don’t have to specify any technical details or tell Robotium where to look for something, such as scrolling down a list when needed. It handles the above and more all on its own.

If you are interested in writing test cases of similar nature have a look at http://www.robotium.org. It makes writing powerful test cases a breeze.