Waiting for a control to become enabled with Espresso

[Alexey Sergeev]

I failed t find a way to wait for a control to become enabled with Espresso. Something similar to UiDevice.wait(...) method.

Does it have that possibility?

Thanks.

[Ewan Benfield]

I do it with this (adapted from a thread on Stack Overflow):

/**
* Return a <code>ViewAction</code> which waits for the underlying
view to be enabled, and
* throws an exception if it is not enabled in time. The view is
checked periodically according
* to the supplied interval and times out when if timeout period is
exceeded
* @param interval The millisecond interval at which to check the view
* @param timeout How long the view should be checked before timeout
* @return
*/
public static ViewAction waitEnabledId(final long interval, final long
timeout) {
return new ViewAction() {
@Override
public Matcher<View> getConstraints() {
return any(View.class);
}

@Override
public String getDescription() {
return "wait for view to be enabled for " + timeout + "
millis.";
}

@Override
public void perform(final UiController uiController, final
View view) {
uiController.loopMainThreadUntilIdle();
final long startTime = System.currentTimeMillis();
final long endTime = startTime + timeout;
do {
if (view.isEnabled())
return;
Log.d(TAG, "Waited so far: " +
(System.currentTimeMillis() - startTime));
uiController.loopMainThreadForAtLeast(interval);
}
while (System.currentTimeMillis() < endTime);

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

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Alexey Sergeev]

Thanks Ewan.

Did you mean that there is no standard API?

[Jose Alcérreca]

We don't recommend going down this road.

It looks more convenient than implementing an idling resource because there's no need to change your code under test. However, it makes execution slower and more prone to breaking since you're depending on an ID that can be modified at any time by anyone working on the layout. This can break tests that are in principle unrelated to the specific View.

--
You received this message because you are subscribed to the Google Groups "Android Testing Support Library" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-testing-suppo...@googlegroups.com.
To post to this group, send email to android-testing...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-testing-support-library/op.yftul8pmss10to%40angela.local.
For more options, visit https://groups.google.com/d/optout.

[Alexey Sergeev]

Thanks Jose,

Do you know a good example of using idling resources for waiting for a view state change?

Here I see another issue. I haven't found a way with Espresso to get a view property like: isEnabled, description ...

To unsubscribe from this group and stop receiving emails from it, send an email to android-testing-support-library+unsubscribe@googlegroups.com.
To post to this group, send email to android-testing-support-lib...@googlegroups.com.

[Jose Alcerreca]

With idling resource you don't wait for a view state to change, you wait for your app to be idle.

In https://github.com/googlesamples/android-architecture we implement a simple one to wait until the repository is back with a response. It works for every screen, no need to look for a View that changes.

[Alexey Sergeev]

But that is not my case. 

One of the test is:

Start the app.

Check the main controls are enabled.

I cannot just do onView().check() as it takes time for controls to become enabled.