When you say "Built-in support for junit test through robolectric will not happen", what do yo mean?
If you mean Robolectric should be integrated with the android gradle plugin, then I agree it shouldn't. If you mean JUnit tests are never gonna be a part of android gradle plugin, then I really want to know why is that. If the Android Gradle plugin allows for Built-in JUnit tests, it will allow testing for pure Java classes (since any dependency to the Android framework should run in an emulator) and in case someone wants to integrate Robolectric, then you would just need to add Robolectric to the classpath, annotate your tests and maybe configure some things here and there. You shouldn't need a whole new plugin just to add Robolectric, specially a plugin that depends on the Android Gradle plugin that can/will change. I think that is precisely the reason Jake Warthon discontinued his plugin and went full instrumentation tests. I agree with Jake that one should use Instrumentation tests in emulator since they are closer to reality than third party frameworks like Robolectric. But I still consider a lot of pure Java classes exist in an Android app that could benefit from JUnit tests. In this Google I/O's conference: https://developers.google.com/events/io/sessions/331474237 Erik Kuefler mentions the advantages of separating the logic in a pure Java class (Presenter) to allow running JUnit tests instead of GWTTestCase. In case of Android it is an even bigger advantage since the emulator is a very slow process compared to JUnit. Just my 2 cents. -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
