Fixed
Status Update
Comments
il...@google.com <il...@google.com>
jh...@themeetgroup.com <jh...@themeetgroup.com> #2
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
ap...@google.com <ap...@google.com> #3
yea i'll take it.
fr...@google.com <fr...@google.com>
an...@google.com <an...@google.com> #4
Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.
sa...@peilicke.de <sa...@peilicke.de> #5
just emitting same live data reproduces the issue.
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
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.