問題描述

我目前正在嘗試測試是否確實收到了網(wǎng)絡(luò)響應(yīng).

I am currently attempting to test that a network response is actually being received.

雖然我知道這不是我在測試方面應(yīng)該做的事情，但這是我自己的好奇心，如果可能的話，我想繼續(xù).

就目前而言，我已經(jīng)成功創(chuàng)建了測試.請求被毫無問題地發(fā)送到排球隊列.

As it stands, I have successfully created the test. A request is sent to a volley queue without issue.

現(xiàn)在奇怪的部分:

該請求永遠不會執(zhí)行.這是我如何測試它的想法:

That request is never executed. Here's an idea of how I'm testing it:

 @Test
    public void testSimpleGetResponseFromServerVolley() throws Exception {
        final CountDownLatch signal = new CountDownLatch(1);

        NetworkClass.NetworkListener listener = new NetworkClass.NetworkListener() {
            @Override
            public void onResponse(Response response) {
                assertThat(response != null);
                System.out.println("Got Response");
                signal.countDown();

            }

            @Override
            public void onError(Throwable error) {
                System.out.println("No Response");
                signal.countDown();
            }
        };
        NetworkClass.getResponseFromServer(null, listener);
        signal.await();
    }

此代碼意外導(dǎo)致測試掛起并且永遠無法完成.

This code unexpectedly causes the test to hang and never complete.

然而，這是我不再對情況失去理解的地方:

如果我通過 debug 運行測試并逐行執(zhí)行，則測試成功執(zhí)行，并收到響應(yīng).

If I run the test via debug and step through line by line, the test successfully executes, and response is received.

我認為正在發(fā)生的事情:

當我通過調(diào)試單步執(zhí)行時，volley requestQueue 成功進行并發(fā)出請求，并在調(diào)用 await() 之前收到響應(yīng).

When I step through via debug, the volley requestQueue successfully carries on and makes the request, and the response is received before await() is called.

當我不通過調(diào)試單步執(zhí)行時，await() 會阻塞處理所有這些的線程.

When I don't step through via debug, await() is blocking the thread which handles all of that.

關(guān)于如何處理這個問題的任何想法?

Any ideas on how I can handle this?

推薦答案

Volley 依賴 Looper.getMainLooper() 來處理其執(zhí)行.當使用 RobolectricTestRunner 時，Robolectric 會對此進行模擬，因此它不會正確設(shè)置，從而導(dǎo)致測試失敗.

Volley relies on Looper.getMainLooper() to handle its executions. When using a RobolectricTestRunner, Robolectric mocks this out and as such it will not be correctly set up, thus resulting in a failed test.

在我的具體情況下，當我使用斷點時，系統(tǒng)實際上確實設(shè)置了主循環(huán)器，因為系統(tǒng)正在利用它來顯示斷點/調(diào)試工具.因此，這描述了我最初的問題中發(fā)現(xiàn)的行為背后的原因.

In my specific case, when I was using breakpoints, the system actually does set up the main looper, because the system is utilizing it to show the breakpoints / debugging tools. This thus describes the reasoning behind the behaviour found in my initial question.

現(xiàn)在，對于在單元測試期間使用 Volley 獲得真實網(wǎng)絡(luò)響應(yīng)的解決方案，必須將執(zhí)行程序更改為不使用主循環(huán)器.

Now for a solution as to getting real network responses with Volley during a unit test, the executor must be changed to not be using the main looper.

作為一個簡單的解決方案，創(chuàng)建一個依賴于 Executor.singleThreadExecutor() 而不是 Main Looper 的請求隊列.

As an easy solution, create a request queue that relies on Executor.singleThreadExecutor() instead of the Main Looper.

這就是我的意思:

    //Specific test queue that uses a singleThreadExecutor instead of the mainLooper for testing purposes.
public RequestQueue newVolleyRequestQueueForTest(final Context context) {
    File cacheDir = new File(context.getCacheDir(), "cache/volley");
    Network network = new BasicNetwork(new HurlStack());
    ResponseDelivery responseDelivery = new ExecutorDelivery(Executors.newSingleThreadExecutor());
    RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir), network, 4, responseDelivery);
    queue.start();
    return queue;
}

然后，在測試期間將其用作 Volley 的請求隊列.

Then, use that as your request queue for Volley during the tests.

這里的關(guān)鍵是:

ResponseDelivery responseDelivery = new ExecutorDelivery(Executors.newSingleThreadExecutor());

希望這會有所幫助！

這篇關(guān)于單元測試網(wǎng)絡(luò)響應(yīng).在調(diào)試時工作，而不是在實際運行時工作的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！