BDD/TDD for Mobile (Android/iOS) Part I: Roboelectric Install

So inspired by the Coursera SaaS class, I have been bashing my head against TDD/BDD for mobile again. Let's document some of my findings.

 Robotium and Roboelectric are black box testing options for Android. I got stuck on Robotelectric needing apache ant >= 1.8 and I just re-came across my install attempts in my browser tabs. So I just got that all set up.

 I did notice that I seemed to have all sorts of ant paraphenalia around. I do of course remember ant reasonably fondly from my intense Java programming days. Certainly with more fondness than Maven.

Anyway, so at the risk of exposing my shaky UNIX sys admin knowledge I found that I had ant installed in a couple of places on my OSX machine, specifically:

/Users/samueljoseph/Code/java_libs/apache-ant-1.7.0
 /usr/share/java/ant-1.7.1
 /usr/share/java/ant-1.8.1
 /usr/share/java/ant-1.8.2

so it turned out that I already had the ant I needed on my OSX, and I had not necessarily needed to pull down ant-1.8.3, but I had done that anyway; but having down that I threw that in there as well

 /usr/share/java/ant-1.8.3

hastily adjusting the groups and owners in what looked like me a neat fashion:


 sudo chown -R root /usr/share/java/ant-1.8.3
 sudo chgrp -R wheel /usr/share/java/ant-1.8.3

although to be honest I am not sure if that will have turned out to be necessary, or even done correctly, and in fact it turned out that my ant from the command line was already pointing to 1.8.2


/usr/bin/ant
unknownc8bcc8da38b2:RobolectricSample samueljoseph$ ls -ls /usr/bin/ant
8 lrwxr-xr-x  1 root  wheel  22 Jan 25 11:36 /usr/bin/ant -> /usr/share/ant/bin/ant
unknownc8bcc8da38b2:RobolectricSample samueljoseph$ ls -la /usr/share/ant
lrwxr-xr-x  1 root  wheel  14 Jan 25 11:36 /usr/share/ant -> java/ant-1.8.2

through a series of symbolic links, and it appears that an ANT_HOME variable set in my .profile file was overriding that.

unknownc8bcc8da38b2:RobolectricSample samueljoseph$ more ~/.profile 

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

export DISPLAY=:0.0

export EDITOR=/usr/bin/nano

export ANT_HOME=/Users/samueljoseph/Code/java_libs/apache-ant-1.7.0

export JAXB_HOME=/Users/samueljoseph/Code/java_libs/jaxb-ri-20070122

export JUNIT_HOME=/Users/samueljoseph/Code/java_libs/junit4.4

export AVETANA_HOME=/Users/samueljoseph/Code/java_libs/avetana-jsr-82/

export BLUECOVE_HOME=/Users/samueljoseph/Code/java_libs/bluecove/

export JAVABT_HOME=$AVETANA_HOME

PROMPT_COMMAND='echo -ne "\033]0; ${PWD/$HOME/~}: ${USER}@${HOSTNAME}\007"'

and removing that ANT_HOME variable there and (I think) running source ~/.profile allowed RoboElectric to run :

Buildfile: /Users/samueljoseph/Code/RobolectricSample/build.xml

clean:

-pre-clean:

clean:

-setup:

     [echo] Gathering info for RoblectricSample...

    [setup] Android SDK Tools Revision 16

    [setup] Project Target: Google APIs

    [setup] Vendor: Google Inc.

    [setup] Platform Version: 2.3.3

    [setup] API level: 10

Although to be honest, I now forget what RoboElectric is actually supposed to be doing.  I had started my poking around with finding a deleted blog article about installing ant on OSX

http://webcache.googleusercontent.com/search?q=cache:X40LT6LETnIJ:gauravstomar.blogspot.com/2011/09/installing-or-upgrading-ant-in-mac-osx.html+&cd=6&hl=en&ct=clnk&gl=uk

Perhaps deservedly deleted due to a number of technical errors.  Either way, between that article and the various symbolic links I discovered I was left no clearer on whether there was some systematic method to manage ant on OSX, and I just went with the one that had greater mass, i.e. the two or three versions of ant in it.  At least on Debian I used to be pretty sure that apt-get was the way to grab software and that on windows all bets were off, and I used to be trying to use ports consistently on OSX, but then that failed when I upgraded the OS, and then it started working again, and now I am just not sure what I am supposed to be doing ...

So working through deleting more tabs, I find that I found some slides that covered some of the different testing options:

http://www.slideshare.net/atobulreddy/android-automation-testing-by-atobulreddy

which reminded me about the Android instrumentation framework, which I do have running.  Actually it seemed I could just run vanilla JUnit tests on peripheral android classes (i.e. ones without android specific functionality) in eclipse on individual classes within my android projects, and when I added a few Android Instrumentation ones (in a separate Android Testing Project, as per instructions) that the existing vanilla JUnit tests also got run anyway, but the Android instrumentation framework, which I think had been painfully slow before, seemed not too bad, particularly if I ran the tests on my externally connected Galaxy Nexus.

There was a blog article that I was following (which I just found yay!) from 2009 talking about the pain of android testing, but perhaps with faster and faster android phones, we can cut out the slow emulator and make android testing less arduous; although I get the sense this Android Instrumentation framework may have been released since that article, or at least the article is trying other approaches that don't work so well.

Of course all this reminds me how frustrating it was that my android talk at the testers workshop last summer was at the same time as a real android expert was talking about android testing, and his talk wasn't recorded (whereas mine was), so anyway ... but back to the slides, which mention Monkey, Robotium and Roboelectric.  I've yet to try Monkey, although there's mention of python so that looks interesting.

So anyhow, it would appear that I downloaded the RoboElectric sample.  And it looks like I was following their github sample project instructions when I got distracted by other work. So "ant debug" now generates an app to be debugged, but I can't run adb till I have an emulator running so now I wait while first eclipse and then the emulator startup, and I reflect how it would be great if I properly documented all of my hacking processes like these, particularly because in the two days prior to hacking on Android BDD/TDD frameworks I had done the same for iOS, and got the OCUnit tests working for iPhone up to a similar level of functionality as I subsequently got the vanilla unit tests working for Android, and found that OCUnit and the Android Instrumentation Framework pretty much paralleled each other in allowing one to simulate button presses in code calls to specific Activities (Android) or Controllers (iOS).

And then in the two days following my attempts to look at Robotium and Roboelectric which interestingly parallel at least some of the capabilities of the OSX Instruments "Automation" framework which I had also been looking at, but as I was saying, in the following two days I had been sucked into iPad development and burned many hours solving little iPad issues, particularly relating to SplitViewControllers, thus the generation of countless tabs of links to places like stackoverflow, burying my tabs on RoboElectric and Ant installation procedures.

BTW, the android emulator is still booting as I write this and it occurs to me I could have just plugged in the Galaxy Nexus ... so I do that, and reflect that it would be nice to be writing out my programming/hacking thoughts and including links to all searches and finds relevant and otherwise, and I speculate about some kind of semi-automated process, but conclude that really I should just keep a blog window open at all times for documentation purposes ...

So the adb doesn't seem to detect the connected Galaxy Nexus, and the emulator is STILL booting and I start to try and close more tabs and find a few other interesting notes to record, such as the android equivalent of iOS popover tabs:

http://stackoverflow.com/questions/5663912/android-popover-controller-same-as-ipad

which don't immediately seem to support the full flexibility of iOS popovers.

But now the emulator is running and I get this error:


unknownc8bcc8da38b2:RobolectricSample samueljoseph$ ./../android-sdk-mac_86/platform-tools/adb -e install bin/RoblectricSample-debug.apk
error: device not found

Googling the error message takes me here:

http://stackoverflow.com/questions/5405562/adb-errordevice-not-found

which reminds me of that command to get the list of devices

unknownc8bcc8da38b2:RobolectricSample samueljoseph$ ./../android-sdk-mac_86/platform-tools/adb devices
List of devices attached
01498B1A16010012 device

which reminds me that RoboElectric won't work with real devices, so I unplug the Nexus, and my emulator is still not in the list:


unknownc8bcc8da38b2:RobolectricSample samueljoseph$ ./../android-sdk-mac_86/platform-tools/adb devices
List of devices attached

unknownc8bcc8da38b2:RobolectricSample samueljoseph$

https://www.google.co.uk/search?q=device+not+showing+in+adb+devices
http://stackoverflow.com/questions/7502011/emulator-not-showing-in-adb-devices

makes me try the following:


unknownc8bcc8da38b2:RobolectricSample samueljoseph$ ./../android-sdk-mac_86/platform-tools/adb kill-server
unknownc8bcc8da38b2:RobolectricSample samueljoseph$ ./../android-sdk-mac_86/platform-tools/adb start-server
unknownc8bcc8da38b2:RobolectricSample samueljoseph$ ./../android-sdk-mac_86/platform-tools/adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
emulator-5554 device

so we are good there, same issue as we often encounter on eclipse - such a pain - what is up with that Google?

So anyway, so then I get:


unknownc8bcc8da38b2:RobolectricSample samueljoseph$ ./../android-sdk-mac_86/platform-tools/adb -e install bin/RoblectricSample-debug.apk
708 KB/s (278190 bytes in 0.383s)
pkg: /data/local/tmp/RoblectricSample-debug.apk
Success

but no tests run.  I can run the app by selecting it, and get a few screens including a pivotal tracker log in, but am left wondering whether I just ran some tests or whether using ant instead of maven broke all this.  I'll add a screenshot and leave it there for the moment.  Looks like I have missed something, or perhaps I just have to write up some of my own tests ...