Robolectric and similar projects have always complained that instrumented unit testing(yes, you can do both tdd an bdd instrumented testing in android development as the plain old unit test classes in the android framework are not loading the tested entity within the android framework system. if you doubt me look at the difference between ActivityInsgtrumentationTestCase2 and ActivityUnitTestCase classes. In Android all TDD unit style test classes have Unit in the class name.) takes more time.

Specifically, its the time to dex the classes and to start the emulator and install the application as when in in TDD mode you are writing the tests first before your application code. Is that that much difference between writing several unit tests for one class waiting more for those tests to finish in instrumented test,mode on the emulator or writing some unit tests for a class running the tests on the emulator while you write more unit tests for another class.

But design shops seem to have bought into less time is more impressive results even though as the android framework matures the results for JVM unit testing it get less and less effective as you cannot predict the behavior of member variables that have been exposed. But, you could speed up unit test writing.

You could use hamcrest matchers and you could build the test-assertions-android github project to get android style fest assertions for the android environment which would act not only to speed up unit test writing but would allow you be able to go back to several unit test results after they are executed and understand them as they are closer to plain English than a regular android unit test with those libraries not applied to a unit test.

This not the only concern however in testing. In Android Instrumented Testing no matter if run it for the IDE or the ant script or from a monkeyrunner python script you have three testing areas; Unit tests, Functional tests, and Performance tests. now lets look back at android sdk build script. Notice in the test-helper-runner macro you do not see an value for running junit runner in multi-file mode. What does multi-file mode do? Well if you use an alternative android -junit-runner with multi-file mode enabled than you test results get grouped by testsuite thus than you have them grouped by; Unit tests, Functional tests, Performance tests.

This is why as of this moment I am rewriting the build scripts supplied with the android sdk as to fully get the benefits of being able to run both TDD and BDD in android instrumented fashion in the IDE those ant script changes will than be applied in setting my IDE java/android builder to use the ant script. And due to the fact that I will have a dashboard generated with the docs during the debug/compile target execution containing such things as Checkstyle, PMD, JavaNCSS, class, and jdepend reports it will be somewhat more effective in getting a snapshot view of the project each time I change code.

Than we have the aspect of some areas are not covered well, regression testing and acceptance testing. Regression testing could be enabled by using monkeyrunner as it has  a user/UI recorder. Now, we do have android-guitar framework which runs on to of monkeyrunner which gives us an event model report but it does not support swipes and some other UI interactions. So we have either extend android guitar or monkeyrunner. Actually that is a nop as monkeyrunner accepts plugins that are written in java and thus the plugins you add to extend monkeyrunner could actually also extend android guitar. Thus, that is another piece I have to add to the testing part of the android app build script, ie the ability to execute the monkeyrunner scripts as part of the instrumented testing developer workflow. Also remember monkeyrunner is an automation tool that is integrated with the android framework api which means anything in the instrumented testing process that can be automated is now reachable to be automated. For example, you could turn off the wakeful lock, etc as part of the process of starting the device or emulator in your instrumented testing process.

This is generally why to rescue an android project you have to start-over the 3rd time, at least in applying agile as you need to change the way tools are integrated together in the developer process and the work-flow and of course the culture. Its not can I buy you coffee and you consult for an hour and the project is rescued type of situation. And my thinking is if you want and value the benefits of full agile, not just TDD and BDD but the change in culture which desire upfront feedback(ie transparency), than you have to be willing to put in the time and costs to change it. Are you willing as company or firm willing to hire a developer to change it? think it about another way.

At one point in internet history we were using Gopher and it basically sucked. At time I watched as people(developers) came up with a better way and people started using it and it was extremely beautiful in its simplicity and implementation and execution. That is the joy of solving hard development problems.