When to use Espresso-Web

Use Espresso-Web to test your hybrid apps, especially the integration of your
app’s native UI components with its WebView
UI components. You can use the Espresso-Web API in conjunction with other
Espresso APIs to fully interact with web elements inside WebView objects.

If you need to test only the WebView itself, and not the
interactions between the WebView and native components in your app, consider
writing a general web test using a framework like WebDriver. If you use a web testing framework, you don’t
need to use an Android device or a Java Virtual Machine, which makes your tests
run more quickly and reliably. That being said, Espresso-Web allows you to reuse
your custom WebDriver atoms, which gives you a lot of flexibility, especially
when writing tests that you plan to run against both standalone web apps and
apps that include an Android UI.

How it works

Similarly to Espresso’s onData()
method, a WebView interaction comprises several Atoms.
WebView interactions use a combination of the Java programming language and a
JavaScript bridge to do their work. Because there is no chance of introducing
race conditions by exposing data from the JavaScript environment—everything
Espresso sees on the Java-based side is an isolated copy—returning data from
Web.WebInteraction
objects is fully supported, allowing you to verify all data that’s returned from
a request.

What is a WebDriver Atom?

The WebDriver framework uses Atoms to find and manipulate web elements
programmatically. Atoms are used by WebDriver to allow browser manipulation. An
Atom is conceptually similar to a
ViewAction, a self-contained
unit that performs an action in your UI. You expose Atoms using a list of
defined methods, such as findElement() and getElement(), to drive the
browser from the user’s point of view. However, if you use the WebDriver
framework directly, Atoms need to be properly orchestrated, requiring logic that
is quite verbose.

Within Espresso, the classes Web
and Web.WebInteraction
wrap this boilerplate and give an Espresso-like feel to interacting with WebView
objects. So in a context of a WebView, Atoms are used as
a substitution to traditional Espresso ViewMatchers and ViewActions.

Common API usage

The onWebView()
method is the main entry point when working with WebView on Android using
Espresso. You use this method to perform Espresso-Web tests, such as the
following:

Kotlin

onWebView()
.withElement(findElement(Locator.ID, "link_2")) // similar to onView(withId(...))
.perform(webClick()) // Similar to perform(click())
// Similar to check(matches(...))
.check(webMatches(getCurrentUrl(), containsString("navigation_2.html")))

Java

onWebView()
.withElement(findElement(Locator.ID, "link_2")) // similar to onView(withId(...))
.perform(webClick()) // Similar to perform(click())
// Similar to check(matches(...))
.check(webMatches(getCurrentUrl(), containsString("navigation_2.html")));

In this example, Espresso-Web locates a DOM element whose ID is "link_2" and
clicks on it. The tool then verifies that the WebView sends a GET request
containing the "navigation_2.html" string.

Note: When executing your tests, the system
performs all WebView interactions using JavaScript. Therefore, to support
JavaScript evaluation, the WebView under test must have JavaScript enabled.

You can force JavaScript to be enabled by overriding afterActivityLaunched() in
the ActivityTestRule and calling onWebView().forceJavascriptEnabled().
Enabling JavaScript may cause the WebView under test to be reloaded. This is
necessary to ensure that AndroidJUnitRunner
loads all needed test infrastructure, including JavaScript interactions:

Common web interactions

Kotlin

onWebView().withElement(findElement(Locator.ID, "teacher"))

Java

onWebView().withElement(findElement(Locator.ID, "teacher"));

[`withContextualElement()`](/reference/androidx/test/espresso/web/sugar/Web.WebInteraction.html#withContextualElement(androidx.test.espresso.web.model.Atom))
references a scoped DOM element within the WebView, relative to another DOM
element. You should call withElement() first to establish the
reference Web.WebInteraction object (DOM element).

Kotlin

Java

reset()
reverts the WebView to its initial state. This is necessary when a prior
action, such as a click, introduces a navigation change that makes
ElementReference and WindowReference objects inaccessible.

Note: Although using reset() is useful when
making assertions against multi-page workflows, such as form submissions,
your tests should usually be limited in scope and focus on a single page.

Example:

Kotlin

onWebView()
.withElement(...)
.perform(...)
.reset()

Java

onWebView()
.withElement(...)
.perform(...)
.reset();

Example

The following example tests whether, after entering text into a WebView and
selecting a Submit button, the same text appears within a different element in
the same WebView:

Java

public static final String MACCHIATO = "Macchiato";
@Test
public void typeTextInInput_clickButton_SubmitsForm() {
// Lazily launch the Activity with a custom start Intent per test.
mActivityRule.launchActivity(withWebFormIntent());
// Selects the WebView in your layout. If you have multiple WebView objects,
// you can also use a matcher to select a given WebView,
// onWebView(withId(R.id.web_view)).
onWebView()
// Find the input element by ID.
.withElement(findElement(Locator.ID, "text_input"))
// Clear previous input and enter new text into the input element.
.perform(clearElement())
.perform(DriverAtoms.webKeys(MACCHIATO))
// Find the "Submit" button and simulate a click using JavaScript.
.withElement(findElement(Locator.ID, "submitBtn"))
.perform(webClick())
// Find the response element by ID, and verify that it contains the
// entered text.
.withElement(findElement(Locator.ID, "response"))
.check(webMatches(getText(), containsString(MACCHIATO)));
}