使用参数化测试后Espresso在第一次测试后如何运行测试会有什么不同吗？
我有两个参数，如果我自己运行它们，它们都运行得很好（如果我将其中一个注释掉，只有一个参数），或者如果我颠倒顺序，第一个参数总是通过。
但由于某些原因，当我一起运行它们时，第二个总是失败。实际上，有一次它并没有失败。没有改变任何东西，它有一次工作。但只有一次。所以可能存在一个错误，但我倾向于认为这是我正在做（或不做）的事情。
发生的实际问题是在测试中途将字段设置为null（根据调试器）。但我似乎无法弄清楚如何或为什么，特别是因为它在第一次测试中没有发生。因此，我无法在代码中找到任何明显的功能，但我也无法看到与Espresso的不同之处。有什么想法吗？
我已经跟着调试器，它向我证明了值已设置，然后由于某种原因，当它暂停当前的Activity以启动对话框时，该值被设置为null。但仅限于第二次测试。在第一次测试的完全相同的情况下，它没有做到这一点。为什么呢？
修改 好吧，我已经进一步缩小了它，但仍然不确定为什么要这样做。它有点奇怪，但我通过调试器发现，第一次测试中的onDetach在第二次测试后被称为 onResume。为什么会这样？
无论如何，这肯定是我遇到问题的原因，因为使值为null的代码来自onDetach，并且该值最初是从onResume中的方法设置的。所以这解释了它。但为什么会这样呢？
此处记录的问题：https://code.google.com/p/android/issues/detail?id=235247
答案 0 :(得分：0)
好的，我找到了解决方案。由于在当前测试中在onResume之后调用了之前测试的onDestroy，因此我将onDestroy中的代码移动到清除我的监听器到onResume的开头。现在，当onResume中的其他代码运行时，它不会因onDestroy的错误时间而无效。通过存储库访问侦听器，该存储库始终保持活动状态。
希望这对所有人来说都是有意义的，以防他们面临类似的问题。到目前为止，我没有注意到这种解决方法的任何副作用。所有测试都通过，手动运行时，实际应用程序也能正常运行。
修改：此解决方法现在导致问题，因此我不得不接受我的回答。原因是当我为结果调用另一个Activity时，当它返回时，监听器在onResume中被杀死。在这种情况下，onDestroy尚未被杀死，因此不会导致此问题。
编辑2和当前解决方案：这个问题对于读者来说有点难以测试，所以我创建了一个测试应用程序和一个更简单的新问题。我已经找到了一个工作解决方案，我在这篇文章中解释过：Espresso not waiting till Activity is destroyed, before creating a new one for the next test
我相信在阅读一些Meta Q＆amp; A时，我更喜欢问题不会被删除，所以我只想在这里留下这个问题。