Wabash Notes

So Wabash is this set of ant scripts that I have been working on to support BDD and test instrumentation and some beginning MonkeyRunner stuff. The last set of steps is to switch to using the DroidDoclet the same one used by the android project.

This way I can combine different documents from child projects right in the same min-doc website along with the codeqa in a consistent manner. Plus for those projects where we might have jsdocs from webview and doxygen docs of C++ code makes it easy to incorporate that as well.

And than the final pain in the rear getting library project builds to work whereas the library project compiles first than the parent project.

Advertisement

WabashDashboard

Here is what the WabashDashboard looks like:

It was kept simple without use of grails-groovy, django, etc as wanted developers to be able to use it on laptops as well as desktops. I just used some effective iframes to make it real damn easy in operation.

The last part of Wabash to add is the ability to execute MonkeyRunner python scripts. Basically Monkeyrunner allows you to install the app and feed mocked user input to app and take screenshots and also install the android test project for the app as well within the same script and run tests.

 

EMMA Report The Android Drinking Game

If you attempt to use the ant scripts in android sdk  you will end up with a blank non-existent emma html report. Apparently you need to change the location of the coverage.em file in the emma report ask as its not in the test project folder.

I now the iphone dev tools are worse but damn it do we need to invent an effing Android drinking game to make the effing point, here?  Any time the supplied ant scripts in the andorid sdk are wrong take  a drink.

Okay, now that is fixed I need to add emma reports to the TDD/jvm tests in Wabash.

Wabash Progress

Most of the feature set is in including support for webkit projects, Native C, etc so that you can use an ant buildscript set with most of the stuff already in place. The last step is the dashboard and I have some interesting choices.

I could choose Groovy Jetty, Grails, RoR, TurboGears, Django, Symfony, etc. But at this point since I will be making use of Android SDK monkeyrunner which is in python, it makes sense to go with a python base such as Django or TurboGears. Than if I virtualenv and virtualenv wrap it makes it real damn easy to keep environments straight while at the same time having the dashboard live a a child project right in the app project directory which means it can serve a double purpose of being the project notes.

Later on I may make a refactoring of the ant stuff into python modules but for right now is very good progress as I will have a 0.0.1 release that only took 7 days of dev time while I was doing other stuff, not bad. For those poking around in Wabash, the Checkstyle, PMD, and android.pro(proguard config) files are 85% finished and you are welcomed to downloading them and re-purposing them. For beginners wait until I have a good set of instructions.

 

Wabash-Progress

The Wabash Dashboard:

Its not very pretty yet and I have to polish some of the reports but both TDD and BDD within the same build system(Wabash) and even some analysis of javascript in the assets folder. You cannot really go fast agile unless your tools work along-side the development workflow. In my case since I am using Eclipse and Robolectric style tests cannot be run from Eclipse, I needed a build tool that could be run from the command line and allow me to switch from TDD to BDD and back without a lot of manual work in the development process.

Seemed better use of my time than spending time preparing free project prototype estimates to certain Chicago MBA startup idiots(Not that all Chicago MBA and startups are idiots, just the ones attempting to get free work form me). Best part is that due to its adherence to portability, you can use it on a 2-cpu core laptop as I avoid hooking into Maven, Hudson-CI(Jenkins_CI), etc to make sure that I can use it on a laptop anywhere.

 

Bug 15366

If you are wondering how to get the build script in the Android Test Project to reference the parent project classes properly look in this bug report as the ant script code fix is posted in the bug report. It assumes that you have the parent project as root and the android test project as a child project.

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.

Android Tools 8.0.1, Eclipse and ANT 1.8.1

First, if you are running android tools 8.0.1 from eclipse than everything works fine. Second, to run build using android tools 8.0.1 or higher outside of eclipse you must use ant 1.8.1 or higher. Most Linux version in theri beta/test repos already have compiled ant 1.8.1 binaries to install to run ant 1.8.1 form the command line.

My AndCooperANT set of build is being kept pre-ADT8, the new ADT8 or higher project is named IndianaANT and will be up in days.

Now for some other good news, it appears that ADT 9.0 may be pushed out December 20th as it fixes some minor bug issues. One of the changes is an ant version check in the custom task.

As far as eclipse, it will not have ant version 1.8.1 until very late in the 3.7 testing cycle and I doubt if eclipse 3.6.2 will include ant 1.8.1. Thus, since ADT 8.0.1 runs fine in eclipse without ant being upgraded in eclipse the best option is update your ant install if you run builds outside of your IDE. If you have not switched your build run outside of IDE to ant 1.8.1 you will notice the side effect of 3rd party libs not being included in the dex and that is due to some behavior changes between ant 1.7.1 and ant 1.8.1.

Android Testing DSL Reprise

Image via Wikipedia

I did some hacking yesterday with Calculon in a attempt to see if it could be extended similar to robotium. Not possible, robotium is the best option..sorry MK(Calculon developer). Thus, we have a IDE plugin or build that runs all the tests at one time and completes a code coverage report along with a DSL syntax to reduce the complexity of writing unit tests.

It will not be as pretty as say Spock, but still it reduces test writing expertise to something manageable.

But Android emulation is unique in that we have to start up anew AVD to test a different device model. The obvious next step is to get some way to start and stop the AVDs in your emulator inventory and run install-app and tests each time and produce test reports for each device model.

Apache ANT is too brittle of DSL to be flexible enough to work as a work-flow testing scenario. This might be an ideal situation to use Gradle in as it uses Groovy’ DSL with the ability to run/execute ant tasks/targets, maven stuff, ivy, etc.

Dependency Injection vs Mock wise I do not see a need in testing to resort to DI if you have Android-Mock available. But maybe some developers prefer to use DI rather Android-Mock, it just seems that yuo are moving your focus away from  tests up the DI chain if you pursue that route.

AndCooperANT 0.1.1.1 Release

There is now a download of the AndCooperANT Android Java Application build tool. Its still alpha with the most tested area being the build.xml script. Of course if you find errors report them in the issues section.

Some of the docs are still in flux at the moment let me know in an issue/bug report of the instructions are unclear.