Using Espresso 3.4.0 + core 1.4.1-alpha04 does not show obvious errors and does not run any tests

[JoseAlcerreca]

Description

Using Espresso 3.4.0 + core 1.4.1-alpha04 does not show obvious errors and does not run any tests

Steps to Reproduce

android/architecture-samples#820

./gradlew cC

Expected Results

Tests run

Actual Results

Starting 0 tests on Galaxy_Nexus_API_29(AVD) - 10

And what's worse: tests do not fail.

Fix: bump androidXTestCoreVersion to 1.4.1-alpha04: https://github.com/android/architecture-samples/pull/824/files

There should be a strict dependency between 1.4.1-alpha04 and espresso 3.5.0-alpha04

[brettchabot]

There is a strict dependency from espresso 3.5.0-alpha04 -> androidx.test.core.1.4.1-alpha04
https://dl.google.com/android/maven2/androidx/test/espresso/espresso-core/3.5.0-alpha04/espresso-core-3.5.0-alpha04.pom

[alexvanyo]

Argh, I think I see what happened.

Due to https://issuetracker.google.com/127986458, we have debugImplementation "androidx.fragment:fragment-testing:1.4.1", which transitively means we have androidx.test:core:1.4.0 in the debug runtime classpath.

Then, even though we have androidx.test.espresso:espresso-core:3.5.0-alpha04 declared (which does have a strict dependency on androidx.test:core:1.4.1-alpha04) that strict dependency is overwritten by the dependency from the non-test debug runtime classpath and we end up with androidx.test:core:1.4.0 anyway, causing those issues.

https://github.com/android/architecture-samples/pull/824/files solved that problem because it added implementation "androidx.test:core:1.4.1-alpha04", which upgraded the debug runtime classpath and actually allows us to have androidx.test:core:1.4.1-alpha04 in tests.

[brettchabot]

ugh yes this situation has come up before. Unfortunately I cannot see a way of solving it on the androidx.test side, although it should be investigated why the error handling was so poor in this case.

FWIW I'm a proponent of the self-instrumenting apks approach, as in theory such a configuration simplifies a lot of these weird edge cases and also might improve test performance.
IIRC there is a gradle option that enables this mode, but I'm having difficulty finding it at the moment.

[GhiathAlbawab0]

I had the same issue and when I attempt to run androidTest with debug I get this exception:

E/AndroidRuntime: FATAL EXCEPTION: Instr: com.androiddevs.HiltInsturmentTestRunner
    Process: com.androiddevs.shoppinglisttestingyt, PID: 13766
    java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/test/platform/io/FileTestStorage;
        at androidx.test.runner.AndroidJUnitRunner.registerTestStorage(AndroidJUnitRunner.java:660)
        at androidx.test.runner.AndroidJUnitRunner.onStart(AndroidJUnitRunner.java:432)
        at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:2189)
     Caused by: java.lang.ClassNotFoundException: Didn't find class "androidx.test.platform.io.FileTestStorage" on path: DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/system/framework/android.test.mock.jar", zip file "/data/app/com.androiddevs.shoppinglisttestingyt.test-2n7LayjuFYdrRtkprkjJtw==/base.apk", zip file "/data/app/com.androiddevs.shoppinglisttestingyt-a5qxJRTzx8vCP91MqmVn-A==/base.apk"],nativeLibraryDirectories=[/data/app/com.androiddevs.shoppinglisttestingyt.test-2n7LayjuFYdrRtkprkjJtw==/lib/x86, /data/app/com.androiddevs.shoppinglisttestingyt-a5qxJRTzx8vCP91MqmVn-A==/lib/x86, /system/lib, /system/product/lib]]
        at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:196)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:379)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
        at androidx.test.runner.AndroidJUnitRunner.registerTestStorage(AndroidJUnitRunner.java:660) 
        at androidx.test.runner.AndroidJUnitRunner.onStart(AndroidJUnitRunner.java:432) 
        at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:2189) 

knowing that HiltInsturmentTestRunner extends AndroidJUnitRunner.
I posted this as it may help you.
thank you for your efforts.

[allanconda-mercari]

Is there an update to this?

[SimonMarquis]

A temporary solution for me was to completely ignore transitive dependencies coming from androidx.fragment:fragment-testing:

debugImplementation("androidx.fragment:fragment-testing:1.4.1") {
  isTransitive = false
}

This solution is easier to implement, especially when you have a large multi-modules build, since you don't "force" dependencies, you don't need to hardcode version numbers, or exclude specific artifacts like in #294 and #481.

@GhiathAlbawab0 the issue you're having is the same, but coming from androidx.test:monitor. Disabling transitive dependencies like shown above will fix you issue.

[rubensousa]

This should be resolved with the following now that fragment is on 1.6.0-alpha04:

debugImplementation("androidx.fragment:fragment-testing-manifest:1.6.0-alpha04")
androidTestImplementation("androidx.fragment:fragment-testing:1.6.0-alpha04")