Paul Butcher

Warning! Android Tools r14 and (sadly, still) r15 seem to have completely broken the Ant build system with regard to both testing and library support. If you haven’t already upgraded, I strongly suggest that you don’t until these problems are addressed. Here are links to some of the problems:

http://code.google.com/p/android/issues/detail?id=21720 http://code.google.com/p/android/issues/detail?id=21304 http://code.google.com/p/android/issues/detail?id=21299 http://code.google.com/p/android/issues/detail?id=21276 http://code.google.com/p/android/issues/detail?id=21194 http://code.google.com/p/android/issues/detail?id=21108 http://code.google.com/p/android/issues/detail?id=20997

In Testing a library project the Android documentation says:

There are two recommended ways of setting up testing on code and resources in a library project:

• You can set up a test project that instruments an application project that depends on the library project. You can then add tests to the project for library-specific features.
• You can set up a set up a standard application project that depends on the library and put the instrumentation in that project. This lets you create a self-contained project that contains both the tests/instrumentations and the code to test.

How to achieve the first of these is pretty obvious, but the second (to me, at least) rather less so. I wasn’t able to find an example, so I thought that I’d post how I managed to get it working.

Although it does work, I’m not 100% happy with it, and there may well be a nicer way to achieve this (see the end of this post for a discussion about my concerns). I would be very grateful for any suggestions for improvements.

Note, we don’t build with Eclipse (partly because we’ve found its reliability leaves a lot to be desired, but mainly because we need a command line build in order to be able to integrate with the rest of our build system and continuous integration server). So all of the following uses the Android command line tools.

The steps

1. Create a new library project as follows:

   android create lib-project -n ExampleLib -t android-8 \
   -p examplelib -k com.example.lib

2. In that project, create src/com/example/lib/Widget.java containing:

   package com.example.lib;
    
   public class Widget {
       public String getColour() {
           return "blue";
       }
    
       public String getDisposition() {
           return "awesome";
       }
   }

3. In the examplelib directory, create a test project with:

   android create test-project -m .. -p test -n ExampleTest

4. Edit the AndroidManifest.xml in the test project and change the line:

   android:targetPackage="com.example.lib"

   to:

   android:targetPackage="com.example.lib.tests"

5. Delete the following line from the build.properties in the test project:

   tested.project.dir=..

   and add the following:

   android.library.reference.1=..

6. Delete the src/com/example/lib/ACTIVITY_ENTRY_NAMETest.java file.
7. Create src/com/example/lib/WidgetTest.java containing:

   package com.example.lib;
    
   import junit.framework.TestCase;
    
   public class WidgetTest extends TestCase {
    
       private Widget widget;
    
       @Override
       protected void setUp() {
           widget = new Widget();
       }
    
       public void testColour() {
           assertEquals("blue", widget.getColour());
       }
    
       public void testDisposition() {
           assertEquals("awesome", widget.getDisposition());
       }
   }

8. Start an emulator and install with ant install.
9. Run the tests with:

   adb shell am instrument \
   -w com.example.lib.tests/android.test.InstrumentationTestRunner

Reservations

It’s clear from the above that the Android tools (the command line tools, at least—perhaps the Eclipse plugin is better?) don’t really fully support this way of working. Not least the fact that they assume that we’re always testing an activity in another application (hence the strangely named ACTIVITY_ENTRY_NAMETest.java file).

1. In step 4, we changed the targetPackage. This is necessary because if we leave it as com.example.lib, Android will try to launch an application with that package name, which doesn’t exist. However, it’s something of a lie to suggest that the targetPackage is com.example.lib.tests
2. In a normal Android test project, we can run the tests by typing:

   ant run-tests

   We have to run the tests explicitly with adb, however, because in step 5, we deleted the tested.project.dir line. If we don’t, the ant build system will try to rebuild the library project (and library projects can’t be build independently).

   An alternative to the solution presented above is to set tested.project.dir to the current directory (.). This enables ant run-tests, but at the expense of building the project twice.

So, it all works, but it’s a bit messy. Suggestions for improvements very welcome!

Update

Updated to simplify WidgetTest to use JUnit directly instead of InstrumentationTestCase.