Android library project with tests, step by step

Welcome to the new “Technical Wizardry” section of the TouchType blog. Here’s where we’ll be sharing a few of the tips and tricks we’ve learned while developing SwiftKey and the Fluency prediction engine that underpins it.

We’re going to start off with a series of articles on Android development (originally published here).

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.javacontaining:

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

3. In the examplelibdirectory, create a test project with:

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

4. Edit the AndroidManifest.xmlin 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.propertiesin 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.javacontaining:

   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!