The trick is to read the full stack-trace of the error. In the middle, there is some crucial piece of information like this: Caused by: java.lang.RuntimeException: Action will not be performed because the target view does not match one or more of the following constraints: at least 90 percent of the view’s area is displayed … Read more
Add these in the newer version: androidTestImplementation ‘com.android.support.test:rules:1.0.2’ androidTestImplementation ‘com.android.support.test:runner:1.0.2’
This slightly long statement works for me: import static android.support.test.espresso.assertion.ViewAssertions.matches; import static android.support.test.espresso.matcher.RootMatchers.withDecorView; import static android.support.test.espresso.matcher.ViewMatchers.isDisplayed; import static android.support.test.espresso.matcher.ViewMatchers.withText; import static org.hamcrest.Matchers.is; import static org.hamcrest.Matchers.not; …. onView(withText(R.string.TOAST_STRING)).inRoot(withDecorView(not(is(getActivity().getWindow().getDecorView())))).check(matches(isDisplayed()));
To verify if dialog appears you can simply check if View with a text that present inside the dialog is shown: onView(withText(“dialogText”)).check(matches(isDisplayed())); or, based on text with id onView(withId(R.id.myDialogTextId)).check(matches(allOf(withText(myDialogText), isDisplayed())); To click on dialogs button do this (button1 – OK, button2 – Cancel): onView(withId(android.R.id.button1)).perform(click()); UPDATE I think is possible since Espresso has multi window support. … Read more
Need to use doesNotExist() instead. Found here. If the view is there in the view hierarchy but in an invisible state (visibility is set to ‘INVISIBLE’), use not(isDisplayed). However, if the view is not there at all in the view hierarchy (e.g. visibility set to ‘GONE’), doesNotExist() is used.
This blog post explains it best. Basically, it is the following: Small: this test doesn’t interact with any file system or network. Medium: Accesses file systems on box which is running tests. Large: Accesses external file systems, networks, etc. Per the Android Developers blog, a small test should take < 100ms, a medium test < … Read more
Full disclosure: I am one of Espresso’s authors. Both Espresso and Robotium are instrumentation-based frameworks, meaning they use Android Instrumentation to inspect and interact with Activities under test. At Google, we started out by using Robotium because it was more convenient than stock instrumentation (hats off to Robotium developers for making it so). However, it … Read more
You can force the annotation library in your test using: androidTestCompile ‘com.android.support:support-annotations:23.1.0’ Something like this: // Force usage of support annotations in the test app, since it is internally used by the runner module. androidTestCompile ‘com.android.support:support-annotations:23.1.0’ androidTestCompile ‘com.android.support.test:runner:0.4.1’ androidTestCompile ‘com.android.support.test:rules:0.4.1’ androidTestCompile ‘com.android.support.test.espresso:espresso-core:2.2.1’ androidTestCompile ‘com.android.support.test.espresso:espresso-intents:2.2.1’ androidTestCompile ‘com.android.support.test.espresso:espresso-web:2.2.1’ Another solution is to use this in the top … Read more
On my mind correct approach will be: /** 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 <” + … Read more
You can do it with customize view action. public class MyViewAction { public static ViewAction clickChildViewWithId(final int id) { return new ViewAction() { @Override public Matcher<View> getConstraints() { return null; } @Override public String getDescription() { return “Click on a child view with specified id.”; } @Override public void perform(UiController uiController, View view) { View … Read more