Thread.sleep( ) mit Espresso

Espresso behauptet, dass es keine Notwendigkeit gibt Thread.sleep() aber mein Code funktioniert nicht, wenn ich ihn nicht einfüge. Ich verbinde mich mit einer IP und während der Verbindung wird ein Fortschrittsdialog angezeigt. ich brauche ein Thread.sleep() aufrufen, um zu warten, bis der Dialog geschlossen wird. Dies ist mein Testcode, wo ich ihn verwende:

    IP.enterIP(); // fills out an IP dialog (this is done with espresso)

    //progress dialog is now shown
    Thread.sleep(1500);

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

Ich habe diesen Code ohne die versucht Thread.sleep() anrufen, aber es heißt R.id.Button existiert nicht. Die einzige Möglichkeit, wie ich es zum Laufen bekomme, ist mit der Thread.sleep() Anruf.

Außerdem habe ich versucht zu ersetzen Thread.sleep() mit Sachen wie getInstrumentation().waitForIdleSync() und immer noch kein Glück.

Ist dies der einzige Weg, dies zu tun? Oder übersehe ich etwas?

Meiner Meinung nach wird der richtige Ansatz sein:

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

Und dann wird das Nutzungsmuster sein:

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

Danke an AlexK für seine tolle Antwort. Es gibt Fälle, in denen Sie den Code etwas verzögern müssen. Es wartet nicht unbedingt auf eine Serverantwort, sondern wartet möglicherweise darauf, dass die Animation abgeschlossen wird. Ich persönlich habe ein Problem mit Espresso idolingResources (ich denke, wir schreiben viele Codezeilen für eine einfache Sache), also habe ich die Vorgehensweise von AlexK in folgenden Code geändert:

/**
 * 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);
        }
    };
}

Sie können also eine erstellen Delay Klasse und fügen Sie diese Methode darin ein, um einfach darauf zugreifen zu können. Sie können es in Ihrer Testklasse auf die gleiche Weise verwenden: onView(isRoot()).perform(waitFor(5000));

Ich bin auf diesen Thread gestoßen, als ich nach einer Antwort auf ein ähnliches Problem gesucht habe, bei dem ich auf eine Serverantwort gewartet und die Sichtbarkeit von Elementen basierend auf der Antwort geändert habe.

Während die obige Lösung definitiv geholfen hat, fand ich sie schließlich dieses hervorragende beispiel von chiuki und verwende diesen Ansatz jetzt als meine Anlaufstelle, wenn ich darauf warte, dass während App-Leerlaufzeiten Aktionen ausgeführt werden.

Ich habe hinzugefügt ElapsedTimeIdlingResource() zu meiner eigenen Utilities-Klasse, kann das jetzt effektiv als Espresso-geeignete Alternative verwenden, und jetzt ist die Verwendung schön und sauber:

// 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);

Ich denke, es ist einfacher, diese Zeile hinzuzufügen:

SystemClock.sleep(1500);

Wartet vor der Rückkehr eine bestimmte Anzahl von Millisekunden (von uptimeMillis). Ähnlich wie sleep(long), löst aber keine InterruptedException aus; interrupt()-Ereignisse werden bis zur nächsten unterbrechbaren Operation verschoben. Kehrt erst zurück, wenn mindestens die angegebene Anzahl von Millisekunden verstrichen ist.

Dies ähnelt dieser Antwort, verwendet jedoch ein Timeout anstelle von Versuchen und kann mit anderen ViewInteractions verkettet werden:

/**
 * 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: AssertionFailedError) {
            Thread.sleep(50)
        }
    } while (System.currentTimeMillis() < endTime)

    throw TimeoutException()
}

Verwendung:

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

Sie können einfach Barista-Methoden verwenden:

BaristaSleepActions.sleep(2000);

BaristaSleepActions.sleep(2, SECONDS);

Barista ist eine Bibliothek, die Espresso umschließt, um zu vermeiden, dass der gesamte Code hinzugefügt wird, der für die akzeptierte Antwort erforderlich ist. Und hier ist ein Link! https://github.com/SchibstedSpain/Barista

Ich bin neu in Codierung und Espresso, also weiß ich, dass die Verwendung des Leerlaufs eine gute und vernünftige Lösung ist, aber ich bin noch nicht intelligent genug, um das zu tun.

Bis ich sachkundiger werde, brauche ich immer noch meine Tests, um irgendwie zu laufen, also benutze ich jetzt diese schmutzige Lösung, die eine Reihe von Versuchen unternimmt, ein Element zu finden, stoppt, wenn es es findet, und wenn nicht, schläft es kurz und startet erneut, bis die maximale Anzahl von Versuchen erreicht ist (die höchste Anzahl von Versuchen lag bisher bei etwa 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;
}

Ich verwende dies in allen Methoden, die Elemente nach ID, Text, Eltern usw. finden:

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