Fixed
Status Update
No update yet.
Comments
il...@google.com
I don't think #1 makes a lot of sense. There are already potentially libraries out there without that metadata.
#2 makes the most sense to me, but in case we cannot be 100% reliable we should allow blacklisting libraries as described in #3. This should probably be handled globally for a project (in gradle.properpies rather than in the DSL)
#2 makes the most sense to me, but in case we cannot be 100% reliable we should allow blacklisting libraries as described in #3. This should probably be handled globally for a project (in gradle.properpies rather than in the DSL)
ap...@google.com
As I have mentioned I don't think there is a silver bullet. #2 does not work on 100% and #1 will take time before devs will provide the metadata. #3 is in my opinion very important to introduce asap, as the developers have no way how to workaround it at this stage. Also in the future there can be any other issue and there is nothing wrong in doing #3 until we figure out something robust (or for instance finally migrate work manager and navigation to androidx that would make #2 a feasible solution).
il...@google.com
Yes, I'm working on #3 right now to unblock users. We can continue thinking about #2.
Description
Component used: fragment-testing
It would be great to have a
FragmentScenario.withFragment()extension function which has equivalent capabilities toActivityScenario.withActivity()(return value, caching and rethrowing of exceptions).If it's helpful, I have added this to one of my tests
ActivityScenario.withActivity(), so I'm not sure if I'm missing any fragment-specific considerations, but it has been working for my use case.