Leveraging androidTestCompile as the configuration results in unnecessary jars on the classpath

[battags]

I was using the previous iteration of this plugin (on Gradle Android Plugin 0.9.x) and have attempted to upgrade to leverage the latest Gradle plugin.

In the previous iteration of the plugin, there was a "testCompile" configuration which kept the classpath separate from the instrumentation test classpath. The new version does not appear to keep that separation.

That appears to cause some problems. For example, for "instrumentation tests" (androidTest) we need to define "dexmaker-mockito" as a dependency in order to have proper Mockito support in android tests. However, for simple unit tests this is not needed and actually causes problems (null pointer exceptions, forcing the addition of the dexcache system property, etc.) when included, meaning one can either have unit tests or android tests, but not both (at least as far as I can tell).

Is there (a) a work-around I am missing or (b) a plan to separate these configurations again?

[battags]

If this is something that you're looking to move towards (the README seems to allude to it), I can see if my employer would allow me to contribute.

[nenick]

Looks like same issue reported here #17

I found no solution with this plugin, but another two where I could separate the dependency.

https://github.com/novoda/gradle-android-test-plugin seperaye robolectric into other module.

https://github.com/JCAndKSolutions/android-unit-test which works more likely to this plugin and looks like it has the dependency separated.

[battags]

JCAndSolutions/android-unit-test unfortunately only works with "android" projects, not "android-library" projects.

[battags]

It looks like this was removed from the readme "Change use of 'androidTestCompile' to 'testCompile' - more like standard Java plugin". Is it no longer part of the roadmap? What is the workaround for people who need both unit tests and android tests?

[codeguru42]

I am also interested in having unit tests separate from android instrumentation tests in the same module.

[battags]

I made a local modification to basically have a configuration flag on whether to consider "androidTest" and "androidTestCompille" to be part of the unit tests (otherwise it just uses "test" and "testCompile"). Is this something you guys would consider or am I forever going to have to maintain a fork?

[battags]

Any comments from the development team on this?

[battags]

Could you guys at least comment on whether you would accept a patch related to this? The project you forked from used to handle this fine and I'm now keeping a local fork to get this functionality working. I'd like to know if I'm wasting my time.

[erd]

In the previous iteration of the plugin, there was a "testCompile" configuration which kept the classpath separate from the instrumentation test classpath. The new version does not appear to keep that separation.

Even with older versions of the plugin, I've never gotten unit tests and integration tests working successfully in the same project. I usually end up putting the unit tests in the same project as the app I'm building and put the integration tests in their own project.

I'm happy to look at a PR.

[erd]

With #129, we piggyback on the Android Gradle plugin's support for unit tests (which has a separate scope for unit tests and integration tests).