Question

我们围绕我们的相机功能进行了一些UI测试，在我们转移到Espresso / JUnit4后，我们从InstrumentationTestRunner切换到AndroidJUnitRunner后，我们无法再运行现有的测试当我们调用getActivity()：

时，由于频繁的RuntimeException而可靠

java.lang.RuntimeException: Could not launch intent Intent { flg=0x14000000 cmp=com.cookbrite.dev/com.cookbrite.ui.ReceiptCaptureActivity (has extras) } within 45 seconds. Perhaps the main thread has not gone idle within a reasonable amount of time? There could be an animation or something constantly repainting the screen. Or the activity is doing network calls on creation? See the threaddump logs. For your reference the last time the event queue was idle before your activity launch request was 1434471981236 and now the last time the queue went idle was: 1434471981236. If these numbers are the same your activity might be hogging the event queue.
at android.support.test.runner.MonitoringInstrumentation.startActivitySync(MonitoringInstrumentation.java:315)
at android.test.InstrumentationTestCase.launchActivityWithIntent(InstrumentationTestCase.java:119)
at android.test.ActivityInstrumentationTestCase2.getActivity(ActivityInstrumentationTestCase2.java:106)
at com.cookbrite.step2_functional.ui.receipt.ReceiptCaptureTest.getActivity(ReceiptCaptureTest.java:43)

为了更好的可读性，这是RuntimeException上的错误消息，作为引用：

无法启动意图Intent {flg = 0x14000000 cmp = com.cookbrite.dev / com.cookbrite.ui.ReceiptCaptureActivity（has 额外的）}在45秒内。也许主线程并没有闲置在合理的时间内？可能有动画或不断重新粉刷屏幕的东西。或者活动正在进行中网络呼吁创作？请参阅threaddump日志。供你参考活动启动前最后一次事件队列空闲请求是1434471981236，现在是队列最后一次空闲是：1434471981236。如果这些数字与您的活动可能相同正在占据事件队列。

我们现有的测试使用Robotium。尝试使用Espresso编写相同的测试产生了类似的错误，这可能是由于相机预览不断更新UI。但是，即使预览设置为INVISIBLE，我们仍然会遇到Espresso这个问题。

有关如何解决此问题的任何想法/指示（除了回到InstrumentationTestRunner）？

Answer 1

错误输出表明测试类扩展了ActivityInstrumentationTestCase2。我不确定搬到新的ActivityTestRule是否会对您的情况产生任何影响，但值得快速检查。将其放在答案而不是注释中以包含示例代码：

@RunWith(AndroidJUnit4.class)
public class ReceiptCaptureTestNew {
    private ReceiptCaptureActivity mReceiptCaptureActivity;

    @Rule
    public ActivityTestRule<mReceiptCaptureActivity> mActivityRule =
            new ActivityTestRule<>(mReceiptCaptureActivity.class);

    @Before
    public void setUp() throws Exception {
        mReceiptCaptureActivity = mActivityRule.getActivity();
    }

    @After
    public void tearDown() throws Exception {
        // Call finish() on all activities in @After to avoid exceptions in
        // later calls to getActivity() in subsequent tests
        mReceiptCaptureActivity.finish();
    }

    @Test
    public void testPreconditions() {
        assertNotNull(mReceiptCaptureActivity);
        assertThat(mReceiptCaptureActivity.hasWindowFocus(), is(true));
    }
}

Answer 2

最后，我们更改了UI以延迟相机预览启动，因此MonitoringInstrumentation不会因为所有UI更新而感到沮丧。此外，即使在SurfaceView或TextureView状态下，只要相机连接，INVISIBLE和GONE都会发布UI更新。这就是MonitoringInstrumentation在我们的案例中放弃的原因。

如果您的测试以常量UI更新开始，您可能需要考虑暂停操作，直到startActivitySync()完成，并且您从getActivity()获得非空结果。

切换到AndroidJUnitRunner后，现有的Android UI测试停止了工作

2 个答案: