Эспрессо: Thread.sleep()

На мой взгляд, правильный подход будет:

/** Perform action of waiting for a specific view id. */
public static ViewAction waitId(final int viewId, final long millis) {
    return new ViewAction() {
        @Override
        public Matcher<View> getConstraints() {
            return isRoot();
        }

        @Override
        public String getDescription() {
            return "wait for a specific view with id <" + viewId + "> during " + millis + " millis.";
        }

        @Override
        public void perform(final UiController uiController, final View view) {
            uiController.loopMainThreadUntilIdle();
            final long startTime = System.currentTimeMillis();
            final long endTime = startTime + millis;
            final Matcher<View> viewMatcher = withId(viewId);

            do {
                for (View child : TreeIterables.breadthFirstViewTraversal(view)) {
                    // found view with required ID
                    if (viewMatcher.matches(child)) {
                        return;
                    }
                }

                uiController.loopMainThreadForAtLeast(50);
            }
            while (System.currentTimeMillis() < endTime);

            // timeout happens
            throw new PerformException.Builder()
                    .withActionDescription(this.getDescription())
                    .withViewDescription(HumanReadables.describe(view))
                    .withCause(new TimeoutException())
                    .build();
        }
    };
}

И тогда схема использования будет:

// wait during 15 seconds for a view
onView(isRoot()).perform(waitId(R.id.dialogEditor, TimeUnit.SECONDS.toMillis(15)));

Спасибо AlexK за его потрясающий ответ. Бывают случаи, когда вам нужно сделать некоторую задержку в коде. Это не обязательно ожидание ответа сервера, но может быть ожидание завершения анимации. У меня лично есть проблема с Espresso idolingResources (я думаю, что мы пишем много строк кода для простой вещи), поэтому я изменил способ, которым AlexK делал, на следующий код:

/**
 * Perform action of waiting for a specific time.
 */
public static ViewAction waitFor(final long millis) {
    return new ViewAction() {
        @Override
        public Matcher<View> getConstraints() {
            return isRoot();
        }

        @Override
        public String getDescription() {
            return "Wait for " + millis + " milliseconds.";
        }

        @Override
        public void perform(UiController uiController, final View view) {
            uiController.loopMainThreadForAtLeast(millis);
        }
    };
}

Таким образом, вы можете создать класс Delay и поместить в него этот метод, чтобы легко получить к нему доступ. Вы можете использовать его в своем тестовом классе таким же образом: onView(isRoot()).perform(waitFor(5000));

Я наткнулся на эту тему, когда искал ответ на аналогичную проблему, когда я ждал ответа сервера и менял видимость элементов на основе ответа.

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

Я добавил ElapsedTimeIdlingResource() в мой собственный класс утилит, теперь можно эффективно использовать его в качестве альтернативы эспрессо, и теперь использование приятно и чисто:

// Make sure Espresso does not time out
IdlingPolicies.setMasterPolicyTimeout(waitingTime * 2, TimeUnit.MILLISECONDS);
IdlingPolicies.setIdlingResourceTimeout(waitingTime * 2, TimeUnit.MILLISECONDS);

// Now we wait
IdlingResource idlingResource = new ElapsedTimeIdlingResource(waitingTime);
Espresso.registerIdlingResources(idlingResource);

// Stop and verify
onView(withId(R.id.toggle_button))
    .check(matches(withText(R.string.stop)))
    .perform(click());
onView(withId(R.id.result))
    .check(matches(withText(success ? R.string.success: R.string.failure)));

// Clean up
Espresso.unregisterIdlingResources(idlingResource);

Я думаю, что проще добавить эту строку:

SystemClock.sleep(1500);

Ожидает заданное количество миллисекунд (uptimeMillis) перед возвратом. Аналогичен sleep(long), но не генерирует InterruptedException; События interrupt() откладываются до следующей прерываемой операции. Не возвращается, пока не истечет указанное количество миллисекунд.

Это похоже на этот ответ, но использует тайм-аут вместо попыток и может быть объединено с другими ViewInteractions:

/**
 * Wait for view to be visible
 */
fun ViewInteraction.waitUntilVisible(timeout: Long): ViewInteraction {
    val startTime = System.currentTimeMillis()
    val endTime = startTime + timeout

    do {
        try {
            check(matches(isDisplayed()))
            return this
        } catch (e: NoMatchingViewException) {
            Thread.sleep(50)
        }
    } while (System.currentTimeMillis() < endTime)

    throw TimeoutException()
}

Применение:

onView(withId(R.id.whatever))
    .waitUntilVisible(5000)
    .perform(click())

Вы можете просто использовать методы бариста:

BaristaSleepActions.sleep(2000);

BaristaSleepActions.sleep(2, SECONDS);

Barista — это библиотека, которая обертывает эспрессо, чтобы избежать добавления всего кода, необходимого для принятого ответа. А вот ссылка! https://github.com/SchibstedSpain/Barista

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

Пока я не стану более осведомленным, мне все еще нужно, чтобы мои тесты как-то запускались, поэтому пока я использую это грязное решение, которое делает несколько попыток найти элемент, останавливается, если он его находит, а если нет, ненадолго спит и запускает снова, пока не будет достигнуто максимальное количество попыток (максимальное количество попыток до сих пор было около 150).

private static boolean waitForElementUntilDisplayed(ViewInteraction element) {
    int i = 0;
    while (i++ < ATTEMPTS) {
        try {
            element.check(matches(isDisplayed()));
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            try {
                Thread.sleep(WAITING_TIME);
            } catch (Exception e1) {
                e.printStackTrace();
            }
        }
    }
    return false;
}

Я использую это во всех методах поиска элементов по идентификатору, тексту, родителю и т. д.:

static ViewInteraction findById(int itemId) {
    ViewInteraction element = onView(withId(itemId));
    waitForElementUntilDisplayed(element);
    return element;
}

Espresso построен так, чтобы избежать вызовов sleep() в тестах. Ваш тест не должен открывать диалоговое окно для ввода IP-адреса, это должно быть ответственностью тестируемого действия.

С другой стороны, ваш UI-тест должен:

• Подождите, пока появится диалоговое окно IP.
• Заполните IP-адрес и нажмите Enter
• Подождите, пока появится ваша кнопка, и нажмите ее.

Тест должен выглядеть примерно так:

// type the IP and press OK
onView (withId (R.id.dialog_ip_edit_text))
  .check (matches(isDisplayed()))
  .perform (typeText("IP-TO-BE-TYPED"));

onView (withText (R.string.dialog_ok_button_title))
  .check (matches(isDisplayed()))
  .perform (click());

// now, wait for the button and click it
onView (withId (R.id.button))
  .check (matches(isDisplayed()))
  .perform (click());

Espresso ждет завершения всего, что происходит как в потоке пользовательского интерфейса, так и в пуле AsyncTask, прежде чем выполнять ваши тесты.

Помните, что ваши тесты не должны делать ничего, за что отвечает ваше приложение. Он должен вести себя как «хорошо информированный пользователь»: пользователь, который нажимает, проверяет, что что-то отображается на экране, но, по сути, знает идентификаторы компонентов.

Вам следует использовать ресурс Espresso Idling, который предлагается по адресу CodeLab

Бездействующий ресурс представляет собой асинхронную операцию, результаты которой влияют на последующие операции в тесте пользовательского интерфейса. Зарегистрировав простаивающие ресурсы в Espresso, вы можете более надежно проверять эти асинхронные операции при тестировании своего приложения.

Пример асинхронного вызова от Presenter

@Override
public void loadNotes(boolean forceUpdate) {
   mNotesView.setProgressIndicator(true);
   if (forceUpdate) {
       mNotesRepository.refreshData();
   }

   // The network request might be handled in a different thread so make sure Espresso knows
   // that the app is busy until the response is handled.
   EspressoIdlingResource.increment(); // App is busy until further notice

   mNotesRepository.getNotes(new NotesRepository.LoadNotesCallback() {
       @Override
       public void onNotesLoaded(List<Note> notes) {
           EspressoIdlingResource.decrement(); // Set app as idle.
           mNotesView.setProgressIndicator(false);
           mNotesView.showNotes(notes);
       }
   });
}

Зависимости

androidTestImplementation 'androidx.test.espresso:espresso-core:3.1.1'
    implementation 'androidx.test.espresso:espresso-idling-resource:3.1.1'

Для androidx

androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
    implementation 'com.android.support.test.espresso:espresso-idling-resource:3.0.2'

Официальный репозиторий: https://github.com/googlecodelabs/android-testing< /а>

Пример IdlingResource: https://github.com/googlesamples/android-testing/tree/master/ui/espresso/IdlingResourceSample

Вы также можете использовать CountDownLatch, чтобы заблокировать поток, пока вы не получите ответ от сервера или тайм-аут.

Защелка обратного отсчета — это простое, но элегантное решение, не требующее внешней библиотеки. Это также помогает вам сосредоточиться на фактической логике, которую нужно протестировать, а не на чрезмерном проектировании асинхронного ожидания или ожидания ответа.

void testServerAPIResponse() {


        Latch latch = new CountDownLatch(1);


        //Do your async job
        Service.doSomething(new Callback() {

            @Override
            public void onResponse(){
                ACTUAL_RESULT = SUCCESS;
                latch.countDown(); // notify the count down latch
                // assertEquals(..
            }

        });

        //Wait for api response async
        try {
            latch.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        assertEquals(expectedResult, ACTUAL_RESULT);

    }

Хотя я считаю, что для этого лучше всего использовать ресурсы бездействия (https://google.github.io/android-testing-support-library/docs/espresso/idling-resource/), возможно, вы могли бы использовать это как запасной вариант:

/**
 * Contains view interactions, view actions and view assertions which allow to set a timeout
 * for finding a view and performing an action/view assertion on it.
 * To be used instead of {@link Espresso}'s methods.
 * 
 * @author Piotr Zawadzki
 */
public class TimeoutEspresso {

    private static final int SLEEP_IN_A_LOOP_TIME = 50;

    private static final long DEFAULT_TIMEOUT_IN_MILLIS = 10 * 1000L;

    /**
     * Use instead of {@link Espresso#onView(Matcher)}
     * @param timeoutInMillis timeout after which an error is thrown
     * @param viewMatcher view matcher to check for view
     * @return view interaction
     */
    public static TimedViewInteraction onViewWithTimeout(long timeoutInMillis, @NonNull final Matcher<View> viewMatcher) {

        final long startTime = System.currentTimeMillis();
        final long endTime = startTime + timeoutInMillis;

        do {
            try {
                return new TimedViewInteraction(Espresso.onView(viewMatcher));
            } catch (NoMatchingViewException ex) {
                //ignore
            }

            SystemClock.sleep(SLEEP_IN_A_LOOP_TIME);
        }
        while (System.currentTimeMillis() < endTime);

        // timeout happens
        throw new PerformException.Builder()
                .withCause(new TimeoutException("Timeout occurred when trying to find: " + viewMatcher.toString()))
                .build();
    }

    /**
     * Use instead of {@link Espresso#onView(Matcher)}.
     * Same as {@link #onViewWithTimeout(long, Matcher)} but with the default timeout {@link #DEFAULT_TIMEOUT_IN_MILLIS}.
     * @param viewMatcher view matcher to check for view
     * @return view interaction
     */
    public static TimedViewInteraction onViewWithTimeout(@NonNull final Matcher<View> viewMatcher) {
        return onViewWithTimeout(DEFAULT_TIMEOUT_IN_MILLIS, viewMatcher);
    }

    /**
     * A wrapper around {@link ViewInteraction} which allows to set timeouts for view actions and assertions.
     */
    public static class TimedViewInteraction {

        private ViewInteraction wrappedViewInteraction;

        public TimedViewInteraction(ViewInteraction wrappedViewInteraction) {
            this.wrappedViewInteraction = wrappedViewInteraction;
        }

        /**
         * @see ViewInteraction#perform(ViewAction...)
         */
        public TimedViewInteraction perform(final ViewAction... viewActions) {
            wrappedViewInteraction.perform(viewActions);
            return this;
        }

        /**
         * {@link ViewInteraction#perform(ViewAction...)} with a timeout of {@link #DEFAULT_TIMEOUT_IN_MILLIS}.
         * @see ViewInteraction#perform(ViewAction...)
         */
        public TimedViewInteraction performWithTimeout(final ViewAction... viewActions) {
            return performWithTimeout(DEFAULT_TIMEOUT_IN_MILLIS, viewActions);
        }

        /**
         * {@link ViewInteraction#perform(ViewAction...)} with a timeout.
         * @see ViewInteraction#perform(ViewAction...)
         */
        public TimedViewInteraction performWithTimeout(long timeoutInMillis, final ViewAction... viewActions) {
            final long startTime = System.currentTimeMillis();
            final long endTime = startTime + timeoutInMillis;

            do {
                try {
                    return perform(viewActions);
                } catch (RuntimeException ex) {
                    //ignore
                }

                SystemClock.sleep(SLEEP_IN_A_LOOP_TIME);
            }
            while (System.currentTimeMillis() < endTime);

            // timeout happens
            throw new PerformException.Builder()
                    .withCause(new TimeoutException("Timeout occurred when trying to perform view actions: " + viewActions))
                    .build();
        }

        /**
         * @see ViewInteraction#withFailureHandler(FailureHandler)
         */
        public TimedViewInteraction withFailureHandler(FailureHandler failureHandler) {
            wrappedViewInteraction.withFailureHandler(failureHandler);
            return this;
        }

        /**
         * @see ViewInteraction#inRoot(Matcher)
         */
        public TimedViewInteraction inRoot(Matcher<Root> rootMatcher) {
            wrappedViewInteraction.inRoot(rootMatcher);
            return this;
        }

        /**
         * @see ViewInteraction#check(ViewAssertion)
         */
        public TimedViewInteraction check(final ViewAssertion viewAssert) {
            wrappedViewInteraction.check(viewAssert);
            return this;
        }

        /**
         * {@link ViewInteraction#check(ViewAssertion)} with a timeout of {@link #DEFAULT_TIMEOUT_IN_MILLIS}.
         * @see ViewInteraction#check(ViewAssertion)
         */
        public TimedViewInteraction checkWithTimeout(final ViewAssertion viewAssert) {
            return checkWithTimeout(DEFAULT_TIMEOUT_IN_MILLIS, viewAssert);
        }

        /**
         * {@link ViewInteraction#check(ViewAssertion)} with a timeout.
         * @see ViewInteraction#check(ViewAssertion)
         */
        public TimedViewInteraction checkWithTimeout(long timeoutInMillis, final ViewAssertion viewAssert) {
            final long startTime = System.currentTimeMillis();
            final long endTime = startTime + timeoutInMillis;

            do {
                try {
                    return check(viewAssert);
                } catch (RuntimeException ex) {
                    //ignore
                }

                SystemClock.sleep(SLEEP_IN_A_LOOP_TIME);
            }
            while (System.currentTimeMillis() < endTime);

            // timeout happens
            throw new PerformException.Builder()
                    .withCause(new TimeoutException("Timeout occurred when trying to check: " + viewAssert.toString()))
                    .build();
        }
    }
}

а затем вызовите его в своем коде, например:

onViewWithTimeout(withId(R.id.button).perform(click());

вместо

onView(withId(R.id.button).perform(click());

Это также позволяет вам добавлять тайм-ауты для действий просмотра и утверждений просмотра.

Это помощник, который я использую в Kotlin для Android-тестов. В моем случае я использую longOperation для имитации ответа сервера, но вы можете настроить его по своему усмотрению.

@Test
fun ensureItemDetailIsCalledForRowClicked() {
    onView(withId(R.id.input_text))
        .perform(ViewActions.typeText(""), ViewActions.closeSoftKeyboard())
    onView(withId(R.id.search_icon)).perform(ViewActions.click())
    longOperation(
        longOperation = { Thread.sleep(1000) },
        callback = {onView(withId(R.id.result_list)).check(isVisible())})
}

private fun longOperation(
    longOperation: ()-> Unit,
    callback: ()-> Unit
){
    Thread{
        longOperation()
        callback()
    }.start()
}

Я добавлю свой способ сделать это в микс:

fun suspendUntilSuccess(actionToSucceed: () -> Unit, iteration : Int = 0) {
    try {
        actionToSucceed.invoke()
    } catch (e: Throwable) {
        Thread.sleep(200)
        val incrementedIteration : Int = iteration + 1
        if (incrementedIteration == 25) {
            fail("Failed after waiting for action to succeed for 5 seconds.")
        }
        suspendUntilSuccess(actionToSucceed, incrementedIteration)
    }
}

Вызывается так:

suspendUntilSuccess({
    checkThat.viewIsVisible(R.id.textView)
})

Вы можете добавить такие параметры, как максимальное количество итераций, длина итерации и т. д., в функцию suspendUntilSuccess.

Я по-прежнему предпочитаю использовать ресурсы бездействия, но когда тесты тормозят, например, из-за медленной анимации на устройстве, я использую эту функцию, и она работает хорошо. Конечно, он может зависать до 5 секунд, как и до сбоя, поэтому это может увеличить время выполнения ваших тестов, если действие, направленное на успех, никогда не увенчается успехом.