Fixed
Status Update
Comments
il...@google.com <il...@google.com>
jh...@themeetgroup.com <jh...@themeetgroup.com> #2
Hi Ed, Thank you so much for these suggestions. I've been reviewing them and merging them in. Hopefully it should be live. I've included a thank you note too in the article.
ap...@google.com <ap...@google.com> #3
Great! Thanks a lot, I'll look for the live updates soon!
fr...@google.com <fr...@google.com>
an...@google.com <an...@google.com> #4
sa...@peilicke.de <sa...@peilicke.de> #5
Using debugImplementation
breaks release unit tests. Normally, I wouldn't care but those are part of ./gradlew build
. Either change the lint check or provide another solution.
po...@gmail.com <po...@gmail.com> #6
Comment has been deleted.
Description
Version used: 1.1.0 (and most others)
Devices/Android versions reproduced on: N/A
The logical way that a developer would choose to add fragment-testing into the androidTest configuration is with:
androidTestImplementation "androidx.fragment:fragment-testing:1.1.0"
but this is invalid for Espresso Tests, because fragment-testing includes an EmptyFragmentActivity class that is used to bootstrap the FragmentScenario. That Activity must exist in the runtime application's Manifest, and it cannot be in the androidTest manifest because those activities can only start in the instrumentation process, not the application's process. Therefore the documentation <
debugImplementation "androidx.fragment:fragment-testing:1.1.0"
There is an open issue to improve the documentation to clarify why it needs to be debugImplementation and not androidTestImplementation, and to call it out as an explicit requirement (so it cannot be perceived to be an oversight). That issue is:
But to better catch this common error, it would great to have a Lint check that will fail if a project tries to include the fragment-testing artifact in the androidTest configuration, when it should instead be debugImplementation.