所以我放弃了。我接近这个问题，因为哦，嘿，这不是太糟糕，我可以写一堆单元测试，我一直保持我的套件绿色。然而，随着事情越来越多，持续集成和测试是一件非常棒的事情。然后我看到哦，Android有emma集成以及非常棒......然后就是它变得非常好。
所以我设置Hudson并让它调用ant build.xml的覆盖目标，sdk中的android可执行文件可以生成。然后它击中了我。
adb -s <emulator> shell am instrument -w ...
永远不会返回不为0的结果代码...因为adb在技术上干净利落，并且通常无论执行的shell命令如何执行。
所以我再次说，哦，这不是太糟糕，我可以用一个解析输出错误的解析器包装adb，如果测试失败，则返回非0结果代码以使我的构建失败。问题是我还想看看哪些测试失败了。我知道eclipse正在做更聪明的事情，所以我深入挖掘并找到你可以通过的额外开关，包括-r标志。
adb -s <emulator> shell am instrument -r -w ...
现在这开始变得复杂，因为输出变得更复杂，而这最初认为简单的任务变得更加激烈。随着这个SDK越来越成熟，我不得不思考，有人忍受了这种痛苦。但是，我只能找到黑盒测试框架，而不是回归测试套件自动化whitebox排序。
欢迎任何建议。