Too strict androidx.fragment:fragment-testing dependency on androidx.test:monitor

[koral--]

This is a follow-up of closed #472
After further investigation it seems that closing reason is incorrect and root cause is also in this repo, not Android junit5.

Relevant posts in #472 thread:
#472 (comment)
and
#472 (comment)

Workaround:

debugImplementation("androidx.fragment:fragment-testing:1.2.0-rc04") {
        exclude(group = "androidx.test", module = "monitor")
    }

[brettchabot]

thanks for the report. androidx.fragment is actually housed in the AOSP repository and uses the Android bug tracker, but I've filed an issue there on your behalf.

[koral--]

OK thanks. Is it on public bugtracker? If so could you post a link, so I'll star/watch it.
I was unable to find such issue on https://issuetracker.google.com/issues?q=fragment-testing

[brettchabot]

Sorry I filed it in an internal tracker. Here was the fragment's teams response

---

It does - a strict dependency would show as [1.2.0].

You just need to add that updated dependency as a debugImplementation dependency to match fragment-testing - you can't upgrade only androidTestImplementation

[Zingam]

Repost (as this is more appropriate location):

Adding any of these in AS 4.1:

    debugImplementation "androidx.fragment:fragment-testing:$fragmentVersion"
    implementation "androidx.test:core:$androidXTestCoreVersion"

causes in the Codelab Test template https://github.com/googlecodelabs/android-testing

2020-04-25 15:23:46.198 9845-9877/com.example.android.architecture.blueprints.todoapp E/AndroidRuntime: FATAL EXCEPTION: Instr: androidx.test.runner.AndroidJUnitRunner
    Process: com.example.android.architecture.blueprints.todoapp, PID: 9845
    java.lang.NoSuchMethodError: No virtual method shouldWaitForActivitiesToComplete()Z in class Landroidx/test/runner/AndroidJUnitRunner; or its super classes (declaration of 'androidx.test.runner.AndroidJUnitRunner' appears in /data/app/com.example.android.architecture.blueprints.todoapp.test-TzswKzRJ_OZa5_QA5tm9Nw==/base.apk)
        at androidx.test.runner.AndroidJUnitRunner.addListenersLegacyOrder(AndroidJUnitRunner.java:442)
        at androidx.test.runner.AndroidJUnitRunner.addListeners(AndroidJUnitRunner.java:423)
        at androidx.test.runner.AndroidJUnitRunner.onStart(AndroidJUnitRunner.java:391)
        at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:2189)

[Zingam]

The above workaround causes:

A problem occurred evaluating project ':app'.
> Could not find method androidx.fragment:fragment-testing:1.3.0-alpha03() for arguments [build_8fs2idkc0k5bycnza2xi7hyf7$_run_closure2$_closure10@5a0888cd] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.

[eugene-ma]

@Zingam

I also got stuck on the fragments part of the testing codelab ("8. Task: Launch a Fragment from a Test"). However, I downloaded the solution code given at the end of the codelab ("12. Solution code"), and it worked just fine. It turns out that the problem came from me updating the versions of the dependencies in the gradle files to the latest versions.

I was able to isolate which dependency was causing the issue by updating each dependency one at a time while checking to see if the tests still work. It is this dependency that is the problem:

androidTestImplementation "androidx.test.espresso:espresso-core:$espressoVersion"

The given value of espressoVersion in the working solution code is '3.2.0-beta01', but I also checked other versions (listed here) to see which versions will cause the problem. It turns out that the last version where it is still good is '3.3.0-alpha02', and the first version that starts to cause the issue is '3.3.0-alpha03'. So in summary, use this at most:

espressoVersion = '3.3.0-alpha02'

@koral--
@brettchabot

There seems to be something funny going on that started with Espresso 3.3.0-alpha03 that is causing this issue. See my comment for @Zingam above.

[Zingam]

@eugene-ma I don't remember much about my troubles I finished the exercises a while ago. What I learned is that you should go to the respective libraries pages and get the version numbers from there and try to match the versions that are in the docs/release notes (for example if you are updating to the latest versions).

That auto-update feature causes more troubles than it helps IHMO.

[koral--]

In my project (not codelab) I update both dependencies regularly to the newest versions and have no issues so far.
The current version of espresso is 3.3.0-rc01.

[eugene-ma]

For the record, all of these versions of Espresso have not worked for me:

• 3.3.0-alpha03
• 3.3.0-alpha04
• 3.3.0-alpha05
• 3.3.0-beta01
• 3.3.0-beta02
• 3.3.0-rc01

[clint22]

@eugene-ma
Only the workaround suggested by you worked for me. The latest espresso version is showing the same error. Any Idea what's causing this issue? Is it because of the different OS's?

[eugene-ma]

@clint22
I have no idea what causes the issue. I only found the fix for it via trial and error.

[mikehardy]

This does not appear to be resolved, and now that the 3.3.x releases of all the test libraries etc have come out, it bit me. Thanks @koral-- for the workaround, excluding the monitor transitive constraint from the fragment-testing dependency allowed my existing unit test suite to pass.

Here is a diff of the dependencies that shows what changes when you either apply the workaround here / exclude the monitor transitive from fragement-testing, or you don't:

mike@isabela:~/work/AnkiDroid/Anki-Android (dependency-updates) % diff dependencies-with-exclude.txt dependencies-no-exclude.txt 
139c139
< |    |    +--- androidx.test:monitor:1.3.0
---
> |    |    +--- androidx.test:monitor:1.3.0 -> 1.2.0
276c276
< |    |    +--- androidx.test:monitor:1.2.0 -> 1.3.0 (*)
---
> |    |    +--- androidx.test:monitor:1.2.0 (*)
278c278
< |    +--- androidx.test:monitor:1.3.0 (*)
---
> |    +--- androidx.test:monitor:1.3.0 -> 1.2.0 (*)
443c443
< +--- androidx.test:monitor:{strictly 1.3.0} -> 1.3.0 (c)
---
> +--- androidx.test:monitor:{strictly 1.2.0} -> 1.2.0 (c)
508c508
< |    |    +--- androidx.test:monitor:1.3.0
---
> |    |    +--- androidx.test:monitor:1.3.0 -> 1.2.0
648c648
< |    |    +--- androidx.test:monitor:1.2.0 -> 1.3.0 (*)
---
> |    |    +--- androidx.test:monitor:1.2.0 (*)
650c650
< |    +--- androidx.test:monitor:1.3.0 (*)
---
> |    +--- androidx.test:monitor:1.3.0 -> 1.2.0 (*)
802a803
> +--- androidx.test:monitor:{strictly 1.2.0} -> 1.2.0 (c)
897a899,900
> |    |    +--- androidx.test:monitor:1.2.0
> |    |    |    \--- androidx.annotation:annotation:1.0.0 -> 1.1.0
1148a1152
> +--- androidx.test:monitor:{strictly 1.2.0} -> 1.2.0 (c)
1194a1199,1200
> |    |    +--- androidx.test:monitor:1.2.0
> |    |    |    \--- androidx.annotation:annotation:1.0.0 -> 1.1.0
3938c3944

Now that the libraries that require this new API are generally available, the lack of an updated fragment-testing with usable transitive dependency version constraints creates a breaking change with no notice situation

[mikehardy]

Just in case anyone else needs it, currently this is exactly how we are using fragment-testing (and why):

    // debugImplementation required vs testImplementation: https://issuetracker.google.com/issues/128612536
    debugImplementation("androidx.fragment:fragment-testing:1.2.5") {
        exclude group:'androidx.test', module:'monitor'
    }