Android UI testing with robotium

I will base this post on the last article: Android ViewFlipper within TabHost for Tabs with different Views ... and better memory footprint, where we had a TabHost and a ViewFlipper. To test that our example is still working, we have to start the app, start the tab example, click on the ViewFlipper then change to Tab2 and press the button. Of course you can do this by hand if you must, which basically always happens when you're in the middle of development -unless you're doing test driven development. But later on, you don't really want to sit there and click a lot, or even worse, enter text with your thick fingers on a tiny android device screen. So a good idea to test the UI is to get it automated in some way. That is where robotium comes into the game.

Writing a basic test

So let's write a test that does what we mentioned above. Go through the view and press everything we got and make sure it behaves the way we want it to.

What we doing here is clicking on the elements we see and clicking on the ones we need to click. We check that we're running the correct activity and that the right texts show up. The test will run fine now, but it's missing some abstraction. If we decide to rename a text later, we have to edit the test case. This is less than optimal. So let's see what we can change to improve the test case.

Changing the application for better testability

Let's take a look at the layout:

We can see, that the Button has a hard wired text. That gives us some trouble later, because we cannot look up the text in the string resources. A good idea is to place the appropriate string in strings.xml and put a reference to it in the layout. This has two benefits. First, we can now look up the string in our test case. Second, we now have all the strings we use in the application in one file. This is particularly helpful if we want to have internationalization in the application.

So here is our "new" button

all we need in the strings.xml now is:

after we did this for all the strings we use we can continue.

Writing a more abstract test

So here is our improved test case. Now we do not need to fear changing strings or internationalization.

Robtium shortcomings

When looking at the robotium java doc I noticed two things so far which bothered me a bit. Maybe I had a wrong approach or didn't quite figure out how to do it.

When entering text via .enterText(int index, String text) I have to select the EditText field via its position in the layout instead of addressing it by its name. So as soon as the layout changes, I have to edit my test. Not so good.

The next thing is, when menus open and the item to click needs a scrolling action first I cannot reach it.

I'll try to tackle those issues and write another post on how to do more complex operations.

Robotium alternatives

To all the Futurama fans, there's another test framework which name has to sound familiar: Calculon. There is a short introduction on the author's blog. I might look into that too.

So stay tuned for updates on Android UI testing.

Check out the project and the test on github.