Espresso未启动活动在参数化测试中进行第二次迭代

Question

Is there something different about how Espresso runs tests after the first one when using parameterised tests?

I have two parameters and they both run just fine if I do them on their own (if I comment one of them out and just have one parameter), or if I reverse the order the first one always passes.

But for some reason when I run them together the second one always fails. Actually, one time it didn't fail. Without changing anything it worked one time. But just once. So it's possible maybe there's a bug but I'm inclined to think it's something I'm doing (or not doing).

The actual problem that occurs is that a field gets set to null halfway through the test (according to the debugger). But I can't seem to figure out how or why, especially since it doesn't happen on the first test. So I can't find anything obvious in the code that's doing it, but I also can't see what's different with Espresso either. Any ideas?

I've followed the debugger where it proved to me that the value is set, and then for some reason when it pauses the current Activity to launch a dialog the value gets set to null. But only on the second test. In this exact same situation on the first test it doesn't do that. Why?

Edit: Ok I've narrowed it down further but still not sure why it's doing this. It's a bit strange but I've discovered through the debugger, that onDetach in the first test is being called after onResume for the second test. Why might that be?

Anyway that's definitely why I'm having a problem as the code that's making the value null originates from onDetach, and the value is originally set from a method in onResume. So that explains it. But why is this happening?

---

Issue logged here: https://code.google.com/p/android/issues/detail?id=235247

Answer 1

Ok I found a solution. Since onDestroy from the previous test is being called after onResume in the current test, I moved the code in onDestroy that clears my listeners to the start of onResume. Now when the other code in onResume runs it's not nullified by the bad timing of onDestroy. The listeners are accessed via the repository which stays active the whole time.

Hopefully this all makes sense to anyone reading in case they face a similar problem. So far I haven't noticed any side effects of this workaround. All the tests pass and the actual app works as well when running manually.

Edit : This workaround is now causing problems so I have to unaccept my answer. The reason is because when I call another Activity for result, when it comes back the listeners are killed in onResume. In this case onDestroy isn't killed yet so would not cause this problem.

Edit 2 and current solution : this question was a bit hard to test for readers so I created a test app and a new simpler question. I've since found a working solution that I've explained in this post: Espresso not waiting till Activity is destroyed, before creating a new one for the next test

I believe based on reading some Meta Q&A's that SO prefers that questions aren't deleted so I'll just leave this question here.