Is there any downside to using UIAutomator with Espresso in the same test?

[mark...@willowtreeapps.com]

We are using a few UIAutomator methods in our tests such as waitForExist() to help address a few pain points of Espresso.

Is there any downside to this?

Has anyone else used this in their testing suites?

[Nick Korostelev]

I'm not sure if there is a downside to mixing both frameworks. 

However, the fact that you're using "waitForExist" usually means that you have a legitimate bug in your code or you didn't configure Espresso correctly (look into idlingResrouces)

[mark...@willowtreeapps.com]

We have read a lot of conflicting opinions on idlingResources, and I've been evaluating using https://github.com/square/RxIdler/ or https://github.com/JakeWharton/okhttp-idling-resource to assist once we eventually implement, but for now have not had the time to actually properly implement idlingResources.

If you have any awesome examples or thoughts/gotchas when implementing could you let me know?

[Gaurav Dalal]

Well, there is no harm in mixing both the frameworks. 

Yes, idling resources is a pain at few points with espresso (like when you are using some custom progress bars or during async network calls) and this is where UiAutomator helps us out. I'm using both the frameworks in one of my android apps and my app also has some screens in react-native (where only UIAutomator helps).

On android native screens you can use following utility methods for below mentioned cases:

1. To check if a view exists or not:

public static boolean checkIfViewExists(ViewInteraction viewInteraction) {
    boolean status = false;
    try {
        viewInteraction.check(matches(isDisplayed()));
        status = true;
    } catch (NoMatchingViewException | NoRemoteEspressoInstanceException e) {
        status = false;
    } catch (Error e) {
        e.printStackTrace();
        status = false;
    }
    return status;

}

public static boolean checkIfViewExists(int elementId, int index) {
    boolean status;
    try {
        onView(withIndex(withId(elementId), index)).check(matches(isDisplayed()));
        status = true;
    } catch (NoMatchingViewException e) {
        status = false;
    } catch (NoRemoteEspressoInstanceException e) {
        status = false;
        Log.d("espessoLog", "Expected View not found.");
    } catch (Error e) {
        e.printStackTrace();
        status = false;
    }
    return status;

}

2. To wait for an element at some index for some duration (in millis):

public static boolean waitForElementWithIndexAndCheckIfExist(int elementId, int index, int timeToWait) {
    try {
        ViewExistInstruction instruction = new ViewExistInstruction(onView(withIndex(withId(elementId), index)));
        ConditionWatcherUtil.waitForCondition(instruction, timeToWait);
        return true;
    } catch (TimeoutException | InterruptedException e) {
        e.printStackTrace();
        takeScreenShot("waitForElementWithIndexAndCheckIfExist");
        return false;
    }
}

In UIAutomator the following method helps to wait for a particular view:

I'm using with content description (you can change it to resource id)

Initialise an object of UIDevice class (say mDevice) and write following to wait till mentioned time:

This will wait for content description on screen till 10 sec and keep on polling the screen every second until a view with this content description appears.

mDevice.wait(Until.hasObject(By.desc("FlightReviewHeader")), 10000);

Similarly we can use the UiScrollable and UiSelector classes in combination with each other to make useful utility methods (like above).

[mark...@willowtreeapps.com]

Gaurav, This is incredibly helpful!! Thank you so much. I love the try catch checks. I really appreciate it.

-Mark