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.

Advertisement

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.

TDD Hardships on Andorid

You would think that implementing Agile-TDD at the build system level for Android Application Development would b the hard part. Not that is not challenging. The hard part seems to get companies and firms to believe that if its implemented right and executed that you have white box QA testing using  this build system framework without the full costs of full blown QA department. Other mobile platforms such as J2ME in which we do not have a full emulator at the OS level and higher which results in  major differences between the J2ME emulator and what appears on the device in several crucial areas. With Android he can be accepted that 95% to 98% of functions/features on the emulator work as advertised exactly the same way on the device because the emulator not only emulates java but the full connection and integration with the device OS and we have device hardware profiles. This means that similar to the iPhone emulator that with the right build/testing system the power is put back in the one developer hands again significantly reducing cots.

I see not only Android OEMs such as Motorola but other firms developing Android applications view my linkedin profile daily. It is not much to throw a small contract my way so that I can finish this Agile-TDD build system development. Am I asking too much for a small Android development gig/contract? I mean due to this use of Agile-TTD rates can be in terms of $50 to $80 per hour due to the time savings in the developmental process. If you are a firm take the last highest cost Android Application development project that was completed. Now, imagine only paying 50% to 75% of that costs.

How To Start Android Emulator using ANT

To start the Android Emulator and proceed to the next ant task, this should work:

<target name="start.emulator">
<parallel>
			<daemons>
				<exec executable="${emulator}">
					<arg value="-avd"/>
					<arg value="${my-avd}"/>
			    </exec>
			</daemons>
		</parallel>

	</target>

It should work. Now this is the emulator in the released SDK as when you build the sdk/emulator from source its creating
its own AVD and configuration file entry to use that avd. But for just the released SDK/emulator it should work.