What steps will reproduce the problem?
1. Have some sort of tests that uses custom idling resources and register them
near the beginning of the test
2. Sometimes afterwards, unregister the idling resource
3. After the idling resource is unregistered, have its ResourceCallback call
onTranstitionToIdle(). (This usually happens naturally, but we explicitly call
it here so we can reproduce the bug)
4. Do something with Espresso (ex: closeSoftKeyboard())
What is the expected output? What do you see instead?
I expect Espresso to keep going without being blocked. What actually happens is
that Espresso thinks that we have busy idling resource and idles with the
message "These resources are not idle: [] " and eventually throw an exception
due to timeout. If we manually remove the ResourceCallback from the idling
resources (and thus prevent onTransitionToIdle() from being called) after
unregistering, then we won't run into this problem.
What version of the product are you using? On what operating system?
Espresso 2.0, ran it on Nexus 7 with Kitkat
Please provide any additional information below.
My theory is that Espresso keeps track of the total number of idling resources
and the number of idling resources that are idle. If those two number matches,
then Espresso keeps going. Otherwise, it blocks. When we call
unregisterIdlingResource, the total count goes to 0. When we call
onTranstitionToIdle() afterwards, the idle count end up being greater than 0.
Thus, those two count doesn't match and Espresso blocks. If this is the case,
then I think Espresso should either remove the ResourceCallback when we
unregister or prevent onTransitionToIdle from doing anything.
Original issue reported on code.google.com by dav...@intrepid.io on 26 Feb 2015 at 5:33
Original issue reported on code.google.com by
dav...@intrepid.io
on 26 Feb 2015 at 5:33