49

I am trying to check to see if a view is displayed with Espresso. Here is some pseudo code to show what I am trying:

if (!Espresso.onView(withId(R.id.someID)).check(doesNotExist()){
   // then do something
 } else {
   // do nothing, or what have you
 }

But my problem is .check(doesNotExist()) does not return boolean. It is just an assertion. With UiAutomator I was able to just do something like so:

 if (UiAutomator.getbyId(SomeId).exists()){
      .....
   }
Chad Bingham
  • 32,650
  • 19
  • 86
  • 115

8 Answers8

107

Conditional logic in tests is undesirable. With that in mind, Espresso's API was designed to guide the test author away from it (by being explicit with test actions and assertions).

Having said that, you can still achieve the above by implementing your own ViewAction and capturing the isDisplayed check (inside the perform method) into an AtomicBoolean.

Another less elegant option - catch the exception that gets thrown by failed check:

    try {
        onView(withText("my button")).check(matches(isDisplayed()));
        //view is displayed logic
    } catch (NoMatchingViewException e) {
        //view not displayed logic
    }

Kotlin version with an extension function:

    fun ViewInteraction.isDisplayed(): Boolean {
        try {
            check(matches(ViewMatchers.isDisplayed()))
            return true
        } catch (e: NoMatchingViewException) {
            return false
        }
    }

    if(onView(withText("my button")).isDisplayed()) {
        //view is displayed logic
    } else {
        //view not displayed logic
    }
Sattar Hummatli
  • 1,360
  • 1
  • 15
  • 26
ValeraZakharov
  • 3,767
  • 2
  • 15
  • 12
  • I have another question for you, is there anything I need to know when switching between activities? When I press a button with espresso, that changes to another activity, I am unable to press any more buttons in the next activity. – Chad Bingham Dec 31 '13 at 18:03
  • 4
    There's nothing special to be done when switching between activities within the process of the instrumented application. If control flow leaves your application, you cannot interact with the UI (this is a limitation of Android instrumentation). – ValeraZakharov Jan 01 '14 at 23:14
  • 7
    Point here is `isDisplayed` only work if the view is inside the screen. On tween animations, view should exists but it may be outside of screen. – Christopher Francisco Feb 03 '16 at 21:56
  • 1
    I didn't have to catch a "NoMatchingViewException" but an "AssertionFailedError" – luckyhandler Sep 17 '16 at 08:53
  • 19
    @ValeraZakharov Conditional logic in *unit* tests may be undesirable, but a UI automation framework is supposed to perform functional tests, not "UI unit tests". Conditional logic is often required to get into a known UI starting state, especially for a test that is deep within both the views and logic of the app. Apps are not linear from a UI perspective. You don't want to start at step 1 every time you want to test step 200, 201, and 202. Does a user reinstall the app every time they want to choose a different menu and see what is displayed? No. – jerimiah797 Jan 24 '17 at 23:58
  • 2
    Developer-written UI tests can and should be deterministic (just like unit tests). Last year, I gave this talk that outlines how you can accomplish this on Android: https://slideslive.com/38897360/a-practical-guide-to-writing-solid-ui-tests-on-android-en. There is a place for having a few end2end UI tests (where you may not be in full control of the environment), but that was not the focus of what Espresso is trying to solve (hence, the API doesn't make it easy). – ValeraZakharov Feb 01 '17 at 19:33
  • 4
    Tying a developer's hands like that is just bad library design. You don't know my use cases. Libraries should make it easy to write code, they should never prevent a developer from writing the code he wants to write. Also, almost every use of Espresso I know is for user interaction tests. Nobody uses it for unit testing. I'm not even convinced unit testing of a graphical component without user interactivity testing is remotely useful- a human looking at the component is far superior to an automated test. – Gabe Sechan Feb 24 '17 at 16:37
  • 1
    Also the entire fact you have a doesNoteExists but no doesExists makes it worse- I can't even decide what direction is a failure. If it just returned a boolean, I could throw a not in. Just a horrible failure of library design. – Gabe Sechan Feb 24 '17 at 16:44
12

I think to mimic UIAutomator you can do this:
(Though, I suggest rethinking your approach to have no conditions.)

ViewInteraction view = onView(withBlah(...)); // supports .inRoot(...) as well
if (exists(view)) {
     view.perform(...);
}

@CheckResult
public static boolean exists(ViewInteraction interaction) {
    try {
        interaction.perform(new ViewAction() {
            @Override public Matcher<View> getConstraints() {
                return any(View.class);
            }
            @Override public String getDescription() {
                return "check for existence";
            }
            @Override public void perform(UiController uiController, View view) {
                // no op, if this is run, then the execution will continue after .perform(...)
            }
        });
        return true;
    } catch (AmbiguousViewMatcherException ex) {
        // if there's any interaction later with the same matcher, that'll fail anyway
        return true; // we found more than one
    } catch (NoMatchingViewException ex) {
        return false;
    } catch (NoMatchingRootException ex) {
        // optional depending on what you think "exists" means
        return false;
    }
}

Also exists without branching can be implemented really simple:

onView(withBlah()).check(exists()); // the opposite of doesNotExist()

public static ViewAssertion exists() {
    return matches(anything());
}

Though most of the time it's worth checking for matches(isDisplayed()) anyway.

TWiStErRob
  • 44,762
  • 26
  • 170
  • 254
  • Using IsInstanceOf.any is working great, but is that the intended import? There's 3 possibilities. – Heinzlmaen Feb 13 '20 at 15:59
  • @Heinzlmaen Maybe `instanceOf(View.class)` would have been cleaner, but I like how `override fun getConstraints() = any(View::class.java)` reads. In the end all 6 of these things will end up creating the same `IsInstanceOf` class. I would use `Matchers.any` (as `Matchers` has the most methods), I treat anything in a hamcrest subpackages as implementation details, so much so that I have them excluded via _AS > Settings > Editor > General > Auto Import > Exclude from ..._. – TWiStErRob Feb 13 '20 at 20:22
9

We need that functionality and I ended up implementing it below:

https://github.com/marcosdiez/espresso_clone

if(onView(withText("click OK to Continue")).exists()){ 
    doSomething(); 
} else { 
   doSomethingElse(); 
}

I hope it is useful for you.

user3411862
  • 147
  • 1
  • 2
9

You check with the below code also. If view is displayed it will click else it will pass on.

onView(withText("OK")).withFailureHandler(new FailureHandler() {
        @Override
        public void handle(Throwable error, Matcher<View> viewMatcher){
        }
    }).check(matches(isDisplayed())).perform(customClick());
Dhiren Mudgil
  • 117
  • 1
  • 5
6

Why no one mentioned:

onView(withId(R.id.some_view_id)).check(matches(not(doesNotExist())))

just add not before doesNotExist. But if you use this logic a lot it's better to use a custom matcher.

David
  • 2,129
  • 25
  • 34
  • This is by far the best and cleanest way of dealing with exists. I am not sure why it didn't get the upvotes it deserves. This should have been the accepted answer. – The_Martian Jun 30 '21 at 17:43
  • The question states that they want to execute different code depending on whether a view exists or not. This answer does not help them do that. – Just The Highlights Dec 18 '21 at 18:18
5

Based on the answer by Dhiren Mudgil, I ended up writing the following method:

public static boolean viewIsDisplayed(int viewId)
{
    final boolean[] isDisplayed = {true};
    onView(withId(viewId)).withFailureHandler(new FailureHandler()
    {
        @Override
        public void handle(Throwable error, Matcher<View> viewMatcher)
        {
            isDisplayed[0] = false;
        }
    }).check(matches(isDisplayed()));
    return isDisplayed[0];
}

I'm using this to help determine which View in a ViewFlipper is currently displayed.

trooper
  • 4,444
  • 5
  • 32
  • 32
2

It's been some time since this issue was stated, but as it is one of the top hit on Google when searching for ways to make sure a view is present, before doing any actions on it in Espresso, I would like to share my very basic way of handling this.

1: Start out by writing an extension to ViewInteraction:

fun ViewInteraction.exists(): Boolean {
val viewExists = AtomicReference<Boolean>()

this.perform(object : ViewAction {
    override fun perform(uiController: UiController?, view: View?) {
        viewExists.set(view != null)
    }

    override fun getConstraints(): Matcher<View>? {
        return Matchers.allOf(ViewMatchers.withEffectiveVisibility(
                ViewMatchers.Visibility.VISIBLE),
                ViewMatchers.isAssignableFrom(View::class.java))
    }

    override fun getDescription(): String {
        return "check if view exists"
    }
})
return viewExists.get()
}

2: Create a simple help method in your base class (to be used in all test classes):

fun viewExists(id: Int): Boolean {
    return try {
        onView(withId(id)).exists()
    } catch (e: RuntimeException) {
        false
    }
}

With this you either get true or false from onView(withId(id)).exists(), or safely catch the RuntimeException and return false.

Normally a simple check to .exists() would be sufficient, but in some cases, like when you are deleting ListView items until non is left -> when the last item is deleted, the ListView might no longer be present, then an Exception is thrown when trying to check if it exists.

3: With the above implementation, it is safe to check if any view exists, since the RuntimeException is handled nicely behind the scene:

if(viewExists(R.id.something)) {
    //do something
}
//do something else
Muhammad Saad Rafique
  • 3,158
  • 1
  • 13
  • 21
2

I think that what Espresso wants you to do is to change your logic to use doesNotExist()

I have for example

        onView(snackBarMatcher).check(doesNotExist())

        onView(withId(R.id.button)).perform(click())
        onView(snackBarMatcher).check(matches(isDisplayed()))


Duncan McGregor
  • 17,665
  • 12
  • 64
  • 118