Espresso vs. UiAutomator

gistfile1.txt

Android's Espresso framework was created as a "gray-box" testing framework, "gray-box" meaning that it's an automated UI testing framework ("black-box") but it has access to the internals of the application ("white-box").

The Appium Espresso driver opens up new capabilities that weren't possible in UiAutomator2. Here are some of the improvements:

* Access to the internal app code
  * Because Espresso has access to internals, we can execute arbitrary methods that are defined within the Android Application
  * Briefly mention the `mobile: backdoor` method (won't go into too much detail, because Rajdeep is already talking about this)
  * Use case: `view-tag` selector. React Native testers wanted the ability to select items by `view-tag` because they didn't want to pollute the accessibility tag with data that would confuse people using screen-readers
  * Warnings: This violates the "black-box"-ness of Appium so use with caution

* Less flakiness thanks to "IdlingResource"
  * Espresso uses a thing called `IdlingResource` (will provide a brief explanation of what it is)
  * What this means is that Espresso blocks on the UI thread until it's idle
  * Use-case: Give a code example in UiAutomator2 that shows waits, delays, etc.... then show an example in Espresso that takes those out
  * Warnings: There is a risk of the UI thread _never_ idling, and test being stuck. Appium works around this, mostly, by disabling animations

* WebAtoms
  * Explain the Chromedriver problems we've had and the version mismatching, and the problem with finding/setting the context
  * Sometimes all you need to do is a few basic operations, like submitting a username/password in an OAuth form
  * Espresso has a library called the `webAtoms` library, which allows us to execute WebDriver atoms on WebViews, without the need for Chromedriver (or any native WebDriver)
  * It uses a Javascript bridge to the WebView, which isn't possible with UiAutomator2, because this, again, is an internal
  * Appium has a `mobile: webAtoms` endpoint
  * Use-case: A native app that uses OAuth and needs to enter username and password into a webview. Show WebAtoms example of enterring username and password and how we don't need to use Chromedriver, or context-switching to pull this off
  * Warnings: WebAtoms is not as powerful as ChromeDriver. It should only be used for convenience sake. If you're testing a WebView app (PhoneGap, Cordova), use ChromeDriver.
  
* Find elements off-screen
  * UiAutomator2 is constrained to selecting elements that are inside of the viewport
  * Finding elements off-screen requires scrolling, checking, scrolling-again until the element is in viewport (show code example)
  * Using Espresso's `onData` matcher, we can target elements off-screen
  * Explain how it uses `Adapter` 
  * Use-case: Write a data matcher for an element that is an Adapter item and is off-screen
  
* You can still use UiAutomator
  * The one problem of all of this, is that you can only run Espresso tests on the AUT (app-under-test).
  * Espresso can't be run on other apps because the other apps are signed
  * No problem, we have the `mobile: uiautomator2` endpoint to take care of those cases
  * Use-case: Show an example navigating to another app