I guess I should explain this. Lets dig into the android framework first.

The Android Activity is something that the framework creates as you are not in complete control in creating it. That is somewhat important as you normally cannot prepare aspect stuff ahead of time to be created thus there are three other ways to be able to get a hold of it. IoC in an object registry pattern using interfaces(ever wonder why games are so big..there is your hint), some way to mock things or dependency injection or both mock and dependency injection.

This means that agile in android application development ha some differences when compared to other environments where you had no memory/storage constraints and could do as many interfaces as you pleased. Thus we have two areas where we can impact development project times. One is testing where we can use both mocks and dependency injection to in a fast manner implement functional testing and the other area is in application development itself by using dependency injection.

This is not to say that TDD is not agile but, and this is extremely important, TDD does not test behavior in of itself. In other words, yes Robolectric can do functional testing if you are using the advanced features but remember you are testing that behavior in non-alike sandbox as a normal JVM application does not take control of certain object/class cobinations like the android framework does ith the activity class.

Now lets backup a second, what about static classes. Normally you wrap a static class in an interface and test the interface. That is why see several mock frameworks used in android application testing such as Android-Mock. Robolectric does something different called shadow classes. The drawback to those shadow classes is that they DO NOT PREDICT THE BEHAVIOR OF MEMBER VARIABLES THAT ARE EXPOSED!

In the android framework what is the most common area where member variables are found? Hint its the GUI. Where is the common area where those fields are exposed to developers using them/ Both the GUI area AND the INDIVIDUAL FRAMEWORKS THAT MAKE UP THE FEATURES of what an application can accomplish on android. this is why when someone claims that robolectric can test behavior of an android application in a reliable fashion, that they may not know what the eff they are talking about.

Its kind of important to dig into the underlying java and computer science to understand the trade-offs to each agile approach. I personally know of the re-factor work that was completed from android 2.0 to android 3.0 and android 4.0 to expose most of the member variables in the android GUI framework and thus as someone relies upon robolectric going forward they are in actuality testing less and less of actual android application behavior not more.

This is why you find two things in the android framework , some basic mock classes and instrumented testing. Both of which were not in android 1.0 and were added later due to the concerns described in previous paragraphs. Yes, it takes a little more time than TDD/Robolectric but the results when implemented correctly are more reliable