The Real Android Agile Problem

Posted: September 13, 2009 in Android, Java, Mobile
Tags:

As you know G1 Androids cannot be updated to anything past Android 1.5. I took a look at how fast the ROM space of the OS is growing per major version and the ROM space of new devices. We will  encounter the same exact problem with the new devices at Android 2.5 or Android 3.0.

So what does that mean?  We have Unit and Mock Test classes changing at both the minor and major versions of the SDK. Thus, if you wanted a true TDD Agile continuous build you must test code against 2 different SDK versions, ie run more than one emulator during the continuous builds to get the unit/mock tests and etc. Thus, part of the solution is a build system set-up with preprocessing support as you wil lbe writing test casses/code that adjusts to the SDK version due to the unit and mock test classes in the framework changing.

Part of the issue is also that you will have the need to run more than one emulator during heap/memory testing. Obviously, grabbing several devices and flashing with hacked up stuff to root is not an ideal solution or waiting for ADP2, ADP3, or etc. What if we treated the emulator instances as test servers? So we need to manage this with a framework that allows it to be set up programmitcally as we do not want to have 3 to 5 terminals open typing commands.

OPSCode has this framework called Chef. Basically using rake/ruby you can write cookbooks that set up the whole infrastructure, in this case its the set up of android emulators. Now remember, in your build system you already have unit/mock test targets. This means that you can use Chef to write a functional white box test bench that calls those Gradle tasks or Ant test targets based on the cookbook test plan.

Basically, that means those Gradle test tasks or ANT test targets should be rewritten to support installing the debug package on a emulator be serial number, if no serial number provided default to 5554 or a similar low number where a single emulator might operate as there will be times where you might not run the build system in conjunction with other emulators through the Chef framework.

That is what baffled me before when starting AndCooper Android Java Application Build System development was how would one set up test plans.

Reblog this post [with Zemanta]
Advertisements
Comments
  1. crashsystems says:

    T-Mobile already said that they plan on releasing a 1.6 (Donut) update for the G1 when it is ready. I’m already running 1.6 on my G1, via the Cyanogenmod build.

  2. Neil says:

    Perhaps you could justify the opening words “as you know”. AFAIK it will be updated to 1.6, although probably no further.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s