Robotium is a black box test kit though. So while I am sure it's useful, I find that things like selenium and UI blackbox testing becomes rather hard to maintain on a changing live product where the design of the UI is under constant iterations.
I think I have something that seems to be meeting my needs. I have Hudson setup to build my test Project whenever any changes happen in my repo. It calls the coverage target on a modified ant build script that I made from basically looking at how the sdk constructed it's build.xml template. It's semi documented how to do this, but basically you end up copy and pasting the entire contents of the appropriate template into your build file and setting the flag import="false" on the setup tag included by default. Then since you can make custom changes at this point, I swapped out adb in the build script to use a custom adb wrapper wherever adb is called. This wrapper simply execs adb and interprets the success or failure of the command by reading stdout and returns a non 0 resultcode if it detects an error in the output. Then I found this, https://github.com/jsankey/android-junit-report, which you can use instead of the standard test runner and it will generate ant junit xml reports on the device for you (Really freakin convenient). I stash the resultcode of the test run, download the reports (emma, and junit xml) and then interpret the resultcode. Hudson later treats the emma report as a build artifact and publishes the reports in a nice fashion integrated with the SCM. It seems to be a pretty simple setup for running suites of unit tests through a device. Much thanks to jsankey again for that tiny but awfully useful bridge. I think I might extend this to include parsing out the performance stuff (ddmlib seems to have some stuff for this as well) and submit that back. -Greg On Nov 3, 1:33 pm, MarcoAndroid <marco...@gmail.com> wrote: > This tool could be useful (integrates with Maven so should integrate > with Hudson):http://code.google.com/p/robotium/ > I still have it on my list as "to look into" :) > > On 3 nov, 07:20, Greg Giacovelli <miyamo...@gmail.com> wrote: > > > > > > > > > So I give in. I approached this problem as an oh hey that's not too > > bad, I can write a bunch of unit tests, and I have been keeping my > > suite green. However as things get more involved continuous > > integration and testing is a great great thing to have. And then I saw > > oh Android has emma integration as well awesome ... and then that's > > where it get's iffy. > > > So I setup Hudson and have it call the coverage target of the ant > > build.xml that the android executable in the sdk can generate. And > > then it hits me. > > > adb -s <emulator> shell am instrument -w ... > > > will never return a result code that is not 0 ... because adb > > technically exited cleanly and usually will regardless of how the > > shell command that executed did. > > > So again I say, Oh that's not too bad, I can just wrap adb with a > > parser that parses output for errors and return a non 0 resultcode to > > fail my build if a test fails. Problem is then I also want to see what > > tests fail. I know eclipse is doing something smarter so I dig deeper > > and find the extra switches you can pass am instrument including the - > > r flag. > > > adb -s <emulator> shell am instrument -r -w ... > > > Now this is starting to get complicated as the output gets more > > complex and this originally thought simple task is getting more > > intense. As this SDK is maturing more I have to think, someone has > > endured this pain and made a kickass way to automate and report on > > these sdk tools and output. Like something complete with performance > > test tracking, code coverage reporting etc. These outputs all exit in > > the SDK but they just have to be adapted to the tools used outside. I > > have to think after a year or two this adapter(s) has to have been > > written. However I have only been able to find blackbox testing > > frameworks and not anything along the lines of regression test suite > > automation of the whitebox sort. > > > Any suggestions welcome. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
