It's impossible to run Android Junit tests on the host machine, in a way that's reliable. However you can run "junit" tests on a device, and this is what the Gradle plugin supports(*)
However, robolectric is a solution that could be considered "good enough" for some so we'll provide hooks for this. What those hooks are is a bit in flux right now. Is it possible to reuse the same sourceSets that contains the "android" tests(*) and run them either on a device or robolectric? I don't think that's the case right now, but I think it would be a nice goal. If that were to happen, yes you would only maybe need to setup the right dependencies and make it run. Right now though that won't work, and so you'll need to create a new sourceSet (which you can't right now because of the java/android plugins incompatibility) and run them separately. This is where the new plugin hooking up into the android one will facilitate this, dealing with variants and stuff. (*) Let me be more clear about things. Unit tests are important, we support them. It's just you need to run them on a device. Running them on a different VM/Environment that is the actual target of the app is non trivial, and unless we have a good solution, we won't support it out of the box. I think there's some confusion due to our sourcesets and dependency configurations naming (instrumentTest). We are planning to renaming these "androidTest" as they actually include Unit tests, instrument tests, and later uiautomator tests. On Tue, Feb 11, 2014 at 11:38 AM, Jürgen Cruz <[email protected]> wrote: > 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. > -- Xavier Ducrohet Android SDK Tech Lead Google Inc. http://developer.android.com | http://tools.android.com Please do not send me questions directly. Thanks! -- 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.
