Единичное тестирование сетевого ответа. Работает при отладке, а не при фактическом запуске

В настоящее время я пытаюсь проверить, что ответ на сеть фактически получен.

Хотя я понимаю, что это не то, что я должен делать в отношении тестирования, его любопытство по моему собственному желанию, и я хотел бы продолжить, если это возможно.

Как бы то ни было, я успешно создал тест. Запрос отправляется в очередь волейбола без проблем.

Теперь нечетная часть:

Этот запрос никогда не выполняется. Вот идея того, как я его тестирую:

@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(); } 

Этот код неожиданно заставляет тест висеть и никогда не заканчивается.

Однако здесь я перестаю осмысливать ситуацию:

Если я запускаю тест через отладку и шаг за шагом по очереди, тест успешно выполняется, и ответ получен.

Я думаю, что это происходит:

Когда я выхожу через отладку, запрос запроса волейбол успешно выполняется и обрабатывает запрос, и ответ получен до вызова функции wait await() .

Когда я не перехожу через debug, await() блокирует поток, который обрабатывает все это.

Любые идеи о том, как я могу справиться с этим?

Solutions Collecting From Web of "Единичное тестирование сетевого ответа. Работает при отладке, а не при фактическом запуске"

Volley полагается на Looper.getMainLooper() для обработки своих исполнений. При использовании RobolectricTestRunner Robolectric издевается над этим, и поэтому он не будет правильно настроен, что приведет к неудачному тесту.

В моем конкретном случае, когда я использовал точки останова, система фактически настраивала основной петлитель, потому что система использует его для отображения инструментов точки останова / отладки. Это, таким образом, описывает рассуждения о поведении, обнаруженном в моем первоначальном вопросе.

Теперь для решения вопроса о получении реальных сетевых ответов с Volley во время единичного теста, исполнитель должен быть изменен, чтобы не использовать основной петлитель.

В качестве простого решения создайте очередь запросов, которая опирается на Executor.singleThreadExecutor() вместо основного 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 во время тестов.

Ключ здесь:

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

Надеюсь это поможет!