Android TDD Build Tool

This is not the tool itself but the Gradle build GUI showing the tool itself.  Because the gradle build lifecycle is tdd based we get that as a foundation and I am just integrating some tools on top of the gradle android plugin such as code analysis tools robolectric, etc.

How much dev time are we saving?  The typical round trip of compiling the parent project, dx-ing, and installing and compiling the instrumented test and than dx-ing it and installing it can be anywhere from a minute for small project to several minutes per a large project and in the TDD process you would  be doing that perhaps a 100 times on typical coding day. That is over 1 to 2 hours in development time savings. That is not counting the savings of not having to fully mock test an android project and thus it is a substantial amount of development time saved.

To those firms in Chicago looking for Android Developers, I am only 43 minutes from downtown Chicago.

Agile Android-In-Anger

There is a tradition in Java when trying to teach a group to relearn coding patterns or best practices to use the -In-Anger in the title. There are two ways essentially, one is to mock everything so as to be able to use TDD via Junit4 testing in a JVM outside of the Android emulator or android device. The other way is to integrate everything in such a way that one can use roboguice, robotium, and android-mock to instrument test code in the android emulator or android device.

With the introduction of caliper(@googlecode) for benchmarking and vogar(@googlecode) for executing both benchmarking and unit tests via the command line to a Dalvik VM either in the emulator or device that it may once again be speedy and fashionable to do TDD via real unit test code instrumentation.

The title to the article series I have come up with is Agile Android-In-Anger. The anger part is due to the myths that still are out there of what code patterns work in android application development and some performance myths about some of those tools such as dependency injection. The plan is to have some articles up at shareme.github.com this next week.

I do expect to fully cover Roboguice, robotium and Android-Mock together.

Android Agile Patterns

You might be wondering why I would spend so much time on integrating things via an ANT or Gradle build tool. The whole idea was to be able to do full application testing from beginning to end similar to the way OEMs do framework testing. In other words the developer should be able to run multiple devices and emulators through suite of  tests that include TDD and BDD unit tests among other UI tests and should get back test reports and screen shots.

Now we all know about Monkey UI Exerciser which is a small java api to drive UI testing events. That is not what I am referring to as we need some type of framework.  So what do we need:

-run multiple devices or emulators

-run the application

-be able to interact with ADB

-generates UI events and screenshots

Something has popped up in that I have not noticed it before, its called Monkeyrunner. Its a jython/python api/framework for driving both the android emulators and android devices. Is has a plugin system for using java to extend it and we have an ANT jtyhon task via dbmstools.

With this amount of control to run full set of test suites on an application on multiple emulators/devices why would you choose robolectric over robotium? Sure you get speed of test execution bu than you are sacrificing being able to run a real full tests suite.

But what about not enough Mock objects?  Let me tel you a secret about android mock  objects. A lot of them are not fully documented yet in examples which is why you really should explore android source code as you can find all sorts of useful mock testing objects that the android framework developers use.

Basically this means that the individual tests are using the device or emulator to run along with android-mock and robotium to provide TDD and BDD gets implemented using Instinct during your coding sessions.  Than at the end of the day you are using Monkeyrunner to run a suite of tests as jtyhon/python script that runs a suite of tests on the application across multiple devices and or emulators.

There are enough emulator add-ons provided by SonyEricsson, Samsung, and Motorola that while it does not cover ever device it does allow you cover enough of the android device space among popular handsets to catch most of the bugs that may be device specific.

Evidently Monkeyrunner has been in the SDK since 2.0 but I did not notice it before. Okay, thus I now know why I should be using robotium over robolectric.

Agile Android Development

Gee, be nice if testing was easier and with the influx of  new frameworks does not make it any easier. The major reason why the average android developer does not unit test from the beginning(TDD) is that in any Virtual Machine mobile environment you run into situations where certain objects are not accessible to test.

Robotium and Calculon attempt to reduce the complexity by overlaying DSL concepts to come up with a new syntax to testing. Than we have droid-sugar/roboelectric which brings different style mocking to the area.

My thinking is why not combine the android port of easymock(Android-Mock) with some DSL syntax and it allows me to re-enforce my android internals knowledge. Plus the problem with mocks, is that effective mocking is on device/emulator the way Android-Mock implemented and with mocking on JVM rather than Dalvik you are doing a lot of extra steps for less effective results.

So AndCalculon is a polite fork of Calculon to integrate Calculon with Android-Mock and see how far I can take it. I will publish more later this week with the bitbucket.org link.

Junit Test Runner for ANT

One of the founders of  Zutubi came up with extending the JUnit TestRunner used in Android to generate xml reports stored on the SD card that than can be pushed down to a desktop folder using an ant task. The blog post is here and github project page is here.

Thus you can now get unit test reports without having to run them in the IDE.

A Mobile Build System

Through my exploration of attempts of an all inclusive ANT build script for Android development I have come to a set of contrary conclusions.  These conclusions while they run counter to the status quo do in fact indicate that some Enterprise and Web techniques can be re-used.

In a mobile system we often have to interface with the Mobile Device Application Environment to employ unit testing which strongly indicates that a centralized builder server is not an ideal option. It is not that we could not run unit tests in a desktop JVM, its that code coverage and mock tests we can do with the mobile framework offer more value as we cannot use class loader stuff in running unit tests of a mobile framework within the desktop JVM.

There are DSL java tools that are coming out that make unit testing easier for  example Calculon, and the introduction blog post about  it.  But the android developer still needs to do unit testing on device or emulator.

And I had an event happen this week that caused me to once again focus on this. now, imagine you are a radio station marketing company. You probably only have o n mobile developer that is forced to develop on Blackberry, iPhone, and Android. So lead developer Ascott decides on the Android application to have SDK 1.5 as base to target 1.5, 1.6, 2.0.1, and 2.1.

If  you  have worked with mediaplayer through those OS versions and dealt with multiple screens you know what errors are going to pop up. Now remember shops like  this typically do not invest in a whit4 box deviceanywhere testing solution as their marketing budget per client for non development stuff is  often far bigger than the budget assigned to mobile application development.

Now what if we had a white-box solution that was easy to use say suing Groovy DSL that could some automatic tests on Android OS versions and device setups in a set of emulator instances. Than to get full re-use of our investment we use Groovy to make the android application build system more powerful and yet simple.

Because its groovy it already builds on the java knowledge and yet gives a DSL to leverage rather than ANT DSL. This reduction in developer use complexity and use at the single developer level than should translate into developers seeing it as benefiting their android development work flow. And the general idea is to have eclipse IDE execute this groovy/gradle build script as its incrementally compiling the project.

There is jvoegele’s android gradle plugin for gradle style android application build scripts but it forces the developer to manualy adjust the proejct each time its created because gradle prefers src/main/java rather than src. Because we are not using a gradle unit  and coverage anyway stick with the Android ANT convention of src.

So the only part is breaking down the building the components of this Groovy/Gradle Android Application build system and using a sample Android Application build so that I am eating my own dog food. The sample   android application will be an Atom/RSS reader. That should be complicated enough to cover unit testing, unit testing coverage, and white box testing implementations along with webkit webview stuff as well.

In the mean-time I am almost finished with an Android Programming knol detailing the ant build script I use. Thus, I should have that up shortly.

TestNotes-Stephen Ng

A Google Engineer, Stephen NG, has produced some notes on Android Unit and Mock testing. The biggest change is that the Android SDK now supports powermock library use in unit testing.

Testing Tip 102

If you have not done already move all your trace files and hprof dump file programming commands to your testcases class. why?

1. Because its called in your Testcase you no longer have to comment it out to publish your application.

2. You can implement a special ant task that triggers or runs that TestCase and dumps the trace and hprof files in your coverage or performance folder for viewing and analysis.

3. If you cannot find the memory miss-use you would be attempting some heavy Monkey UI test runs with -hprof enabled anyway thus there really i snot another case where you would actually need full hprof on the entire application and all its functions.

UDD vs TDD

You do know if you find someone advocating TDD for Mobile Applications and UDD for the underlying OS development to run like hell, right? Why? Because User Driven Development where the unit tests are not set in stone until middle  or end of development is what actually works for mobile application development. Think about it, when do you do optimization? Which is first optimization or unit testing?

And you will see some hype companies claiming its otherwise, including some OEMs that should know better.

Build Apps the Android 2 Way

Build tip secret:

1. Install Sdk components the android 2.0 way, ie andorid sdk 1.5, 1.6, and 2.0 in same install folder.

2. use build.template as your build template.

3. Copy android_rules.template main node from  Android 2.0/templates into your build file and set setup import to false.

4. Set build.porperies extra values the Android 2.0 way such as tested.absolute.dir, etc.

5. Copy android_tested_rules.template from android 2.0/templates to your build file.

6. define new ant test targets using the comand-line args at:

http://developer.android.com/reference/android/test/InstrumentationTestRunner.html

This should not only give you EMMA coverage support across sdk 1.5, 1.6, and 2.0 but allow you to also test run unit tests with the new tests as separate project set up. Thank the Google engineers on the SDK tools team.