You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for ConditionWatcher! It really helped get me away from littering production code with references to Idling Resources.
In our project (which uses Kotlin), we've added some helper functions to allow us to tie directly into Espresso's functions so that we can mimic the withId() and .check(matches(...)) syntax. This allows us to do this:
This eliminates the need for having to deal with activity or test context, and the implementation is fairly trivial (again, this is Kotlin):
/** * Waits for the view specified by the matcher meats the specified condition*/funwaitForView(viewMatcher:Matcher<View>) =ViewMatcherWaiter(viewMatcher)
/** * Used by the waitForView() shorthand fluent function*/classViewMatcherWaiter constructor(valviewMatcher:Matcher<View>) {
/** * Specify the Espresso matches which will satisfy the condition*/funtoMatch(viewChecker:Matcher<View>) = waitForCondition(object:Instruction() {
overridefungetDescription(): String {
val desc =StringDescription()
desc.appendText("Wait for view ")
viewMatcher.describeTo(desc)
desc.appendText(" to match ")
viewChecker.describeTo(desc)
return desc.toString()
}
overridefuncheckCondition(): Boolean {
returntry {
onView(viewMatcher).check(matches(viewChecker))
true
} catch (x:AssertionError) {
false
}
}
})
}
It also produces nice error messages on timeout:
java.lang.Exception: Wait for view with id: your.package.here.mock:id/searchfield_clearbutton to match (is displayed on the screen to the user and is enabled) - took more than 5 seconds. Test stopped.
This feels very natural to people familiar with Espresso testing and I think it would make a nice addition to your library. Your matchers can get as complex as Espresso allows without having to write custom Instruction classes.
The text was updated successfully, but these errors were encountered:
Thanks for
ConditionWatcher
! It really helped get me away from littering production code with references to Idling Resources.In our project (which uses Kotlin), we've added some helper functions to allow us to tie directly into Espresso's functions so that we can mimic the
withId()
and.check(matches(...))
syntax. This allows us to do this:waitForView(withId(R.id.searchfield_clearbutton)).toMatch(allOf(isDisplayed(), isEnabled()))
This eliminates the need for having to deal with activity or test context, and the implementation is fairly trivial (again, this is Kotlin):
It also produces nice error messages on timeout:
This feels very natural to people familiar with Espresso testing and I think it would make a nice addition to your library. Your matchers can get as complex as Espresso allows without having to write custom
Instruction
classes.The text was updated successfully, but these errors were encountered: