But thankfully after thinking of it some more I can just use ddmlib to get the data from adb's output. I think this will work much better than what I can find.
On Nov 3, 10:38 am, Greg Giacovelli <miyamo...@gmail.com> wrote: > Sadly after looking over monkey runner, it's a java program running a > python interpretter doing the same thing as what I have been writing > but with a GUI. Sorry this is not what I am looking for. > > I guess I was hoping for at least an object model for the raw output > interpreter of a test or suite of tests so that we can write tools to > get useful information into dash boards. I would like to Create junit > reports, dashboards etc. > > -Greg > > On Nov 3, 10:08 am, "A. Elk" <lancaster.dambust...@gmail.com> wrote: > > > > > > > > > The open source SDK now has a tool called monkeyrunner, with an API > > for starting instrumentation from within a Python script. The call (in > > essence) returns a string containing the test results, as if you had > > intercepted the output from am instrument. One of the API methods > > prints out some help, and a little birdie has told me that more docs > > will be made available. > > > Elk > > > On Nov 2, 11:20 pm, Greg Giacovelli <miyamo...@gmail.com> wro > > > > 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