Android library project with tests, step by step

May 4, 2011

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:
  2. In that project, create src/com/example/lib/Widget.javacontaining:
  3. In the examplelibdirectory, create a test project with:
  4. Edit the AndroidManifest.xmlin the test project and change the line:

    to:
  5. Delete the following line from the build.propertiesin the test project:

    and add the following:
  6. Delete the src/com/example/lib/ACTIVITY_ENTRY_NAMETest.java file.
  7. Create src/com/example/lib/WidgetTest.javacontaining:
  8. Start an emulator and install with ant install.
  9. Run the tests with:

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:

    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!