seeing test pollution between robolectric and espresso tests

[jam1401]

This plugin has been working great then I added dagger to my application.The application and robolectric tests have different object graphs so I can inject test objects. Now when I run the espresso tests I get the following error

:dexDebugTest
:processDebugTestJavaRes UP-TO-DATE
:packageDebugTest
:assembleDebugTest
:connectedInstrumentTest
Tests on Samsung Galaxy S4 - 4.3 - API 18 - 1080x1920 - 4.3 failed: Instrumentation run failed due to 'java.lang.IllegalAccessError'

adb logcat reveals the actual error

W/dalvikvm( 3724): Class resolved by unexpected DEX: Lcom/samsung/sra/precog/PrecogApplication;(0xa4e560a8):0x976a0000 ref [Ldagger/ObjectGraph;] Ldagger/ObjectGraph;(0xa4e560a8):0x976d8000
W/dalvikvm( 3724): (Lcom/samsung/sra/precog/PrecogApplication; had used a different Ldagger/ObjectGraph; during pre-verification)
D/AndroidRuntime( 3724): Shutting down VM
W/dalvikvm( 3724): threadid=1: thread exiting with uncaught exception (group=0xa4ba9648)
D/AndroidRuntime( 3714): Shutting down VM
D/jdwp ( 3714): Got wake-up signal, bailing out of select
D/dalvikvm( 3714): Debugger has detached; object registry had 1 entries
E/AndroidRuntime( 3724): FATAL EXCEPTION: main
E/AndroidRuntime( 3724): java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
E/AndroidRuntime( 3724): at com.samsung.sra.precog.PrecogApplication.onCreate(PrecogApplication.java:24)
E/AndroidRuntime( 3724): at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1007)
E/AndroidRuntime( 3724): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4444)
E/AndroidRuntime( 3724): at android.app.ActivityThread.access$1300(ActivityThread.java:141)
E/AndroidRuntime( 3724): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1316)
E/AndroidRuntime( 3724): at android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 3724): at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime( 3724): at android.app.ActivityThread.main(ActivityThread.java:5103)
E/AndroidRuntime( 3724): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 3724): at java.lang.reflect.Method.invoke(Method.java:525)
E/AndroidRuntime( 3724): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:737)
E/AndroidRuntime( 3724): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
E/AndroidRuntime( 3724): at dalvik.system.NativeStart.main(Native Method)
W/ActivityManager( 2254): Error in app com.samsung.sra.precog running instrumentation ComponentInfo{com.samsung.sra.precog.test/com.google.android.apps.common.testing.testrunner.GoogleInstrumentationTestRunner}:
W/ActivityManager( 2254): java.lang.IllegalAccessError
W/ActivityManager( 2254): java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
I/ActivityManager( 2254): Force stopping package com.samsung.sra.precog appid=10054 user=0

The only thing I can think is happening is that when the espresso testsuite is verified it is finding the object graph in the robolectric TestApplication because all the source in src/test is being compiled. But then at runtime is finds that it is now the actually application. This being the indicator from the logcat . Lcom/samsung/sra/precog/PrecogApplication;(0xa4e560a8):0x976a0000 ref [Ldagger/ObjectGraph;] Ldagger/ObjectGraph;(0xa4e560a8):0x976d8000
W/dalvikvm( 3724): (Lcom/samsung/sra/precog/PrecogApplication; had used a different Ldagger/ObjectGraph; during pre-verification)

I can seem to find a configuration that works around this....

[nenick]

I also had this issue and it feels like it slow down compilation and execution for espresso tests.

Until it can be fixed I prefer to separate espresso or robolectric from main module. My working solution is to put robolectric in its own module. Ask if you interested for an example project.

[jam1401]

Yes I would be interested in an example Im trying to get a clean template together I use within my team.

[nenick]

This weekend I try to support coveralls. so don't wonder about test commits

https://github.com/nenick/android-gradle-template

[mag]

Just catching up to this thread...

The plugin is indeed written to use a single source set for both espresso and robolectric tests, which doesn't seem to work in this case. And after talking to the ADT folks, I've realized that a lot of the build tooling and IDE support wants instrumentation tests in a separate source set.

Our original thought for keeping both types of tests in the same source set was that they would want to share some code, but that can be achieved in other ways.

[bparent]

Another issue is the dex method limit. When I counted the methods in deckard-gradle's test apk I see 58,201 methods!

EDIT:

Adding "maven-ant-tasks" to the excluded modules, dropped the method count to 40,520

[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).