One of the new features of Appium 1.12 is a new selector strategy for Android (Espresso only) called -android datamatcher. This new selector strategy makes use of Espresso's data matcher.
A challenge for selecting elements with Android is selecting elements that aren't rendered on the screen. Take this example:
(TODO: Mention the multiple adapterView problem and the solution)
(TODO: Show an example of JSON for selecting with equivalent Java code)
The proof of concept is a monorepo with Lerna, where the repo has scoped NPM packages that export drivers (@appium/xcuitest-driver, @appium/espresso-driver, etc...). The package appium is a CLI that installs and manages these drivers.
@appium/builder, which does almost exactly what appium/appium@1 does, except instead of running the Appium server, it exposes an API that is used to build and run an Appium server.//example usage
| 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 |
| Daniel-Graham-SL0192:appium-espresso-driver danielgraham$ node . | |
| info Espresso Android Espresso Driver listening on http://localhost:4884 | |
| info HTTP --> POST /wd/hub/session | |
| info HTTP {"desiredCapabilities":{"app":"/Users/danielgraham/sandbox/VodQA.apk","automationName":"Espresso","deviceName":"Android Emulator","forceEspressoRebuild":true,"fullReset":true,"newCommandTimeout":700000,"platformName":"Android","connectHardwareKeyboard":true}} | |
| dbug MJSONWP Calling EspressoDriver.createSession() with args: [{"app":"/Users/danielgraham/sandbox/VodQA.apk","automationName":"Espresso","deviceName":"Android Emulator","forceEspressoRebuild":true,"fullReset":true,"newCommandTimeout":700000,"platformName":"Android","connectHardwareKeyboard":true},null,null] | |
| dbug BaseDriver Event 'newSessionRequested' logged at 1539982592736 (13:56:32 GMT-0700 (Pacific Daylight Time)) | |
| dbug BaseDriver Creating session with MJSONWP desired capabilities: {"app":"/Users/danielgraham... | |
| WARN BaseDriver The following capabilities were provided, b |
| [debug] [RemoteDebugger] Page changed: {"1":{"WIRTitleKey":"Tryit Editor v3.5","WIRTypeKey":"WIRTypeWeb","WIRURLKey":"https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_link_target","WIRPageIdentifierKey":1,"WIRConnectionIdentifierKey":"4bbdf887-934c-437d-a183-1efcb1873c22"}} | |
| [debug] [iOS] Remote debugger notified us of a new page listing: {"appIdKey":"44998","pageArray":[{"id":1,"title":"Tryit Editor v3.5","url":"https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_link_target","isKey":true}]} | |
| [debug] [iOS] Checking if page needs to load | |
| [debug] [iOS] New page listing is same as old, doing nothing | |
| [debug] [RemoteDebugger] Frame navigated, unloading page | |
| [debug] [RemoteDebugger] Frame navigated, unloading page | |
| [debug] [RemoteDebugger] Page changed: {"1":{"WIRTitleKey":"Tryit Editor v3.5","WIRTypeKey":"WIRTypeWeb","WIRURLKey":"https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_link_target","WIRPageIdentifierKey":1,"WIRConnectionIdentifierKey":"4bbdf887-934c-437d-a183-1efcb1873c22"}} | |
| [debug] |
| ## Summary | |
| The [proof of concept](https://github.com/dpgraham/appium/tree/dpgraham-monorepo) is a monorepo with [Lerna](https://lernajs.io), where the repo has scoped NPM packages that export drivers (`@appium/xcuitest-driver`, `@appium/espresso-driver`, etc...). The package `appium` is a CLI that installs and manages these drivers. | |
| ## Description | |
| * Appium 1.x imports and bundles together all drivers. The PoC breaks Appium into different packages. | |
| * One package is `@appium/builder`, which does almost exactly what `appium/appium@1` does, except instead of running the Appium server, it exposes an API that is used to build and run an Appium server. | |
| ``` | |
| //example usage |
| #### /test/functional/basic | |
| 104 passing (25m) | |
| 19 pending | |
| 13 failing | |
| 1) XCUITestDriver - element(s) | |
| interactions | |
| text fields | |
| set value |
| bug MJSONWP Calling XCUITestDriver.findElements() with args: ["-ios predicate string","visible = 1","948c7ce9-7574-42f6-a600-0c7885f61029"] | |
| dbug XCUITest Executing command 'findElements' | |
| dbug BaseDriver Valid locator strategies for this request: xpath, id, name, class name, -ios predicate string, -ios class chain, accessibility id | |
| dbug BaseDriver Waiting up to 5000 ms for condition | |
| dbug JSONWP Proxy Matched '/elements' to command name 'findElements' | |
| dbug JSONWP Proxy Proxying [POST /elements] to [POST http://localhost:8100/session/6155DF94-376C-4673-A8E6-6FA6FFC2E18B/elements] with body: {"using":"predicate string","value":"visible = 1"} | |
| info Xcode t = 67.43s Snapshot accessibility hierarchy for app with pid 93495 | |
| info Xcode | |
| info Xcode t = 67.56s Snapshot accessibility hierarchy for app with pid 93495 | |
| info Xcode |
| 76 passing (1h) | |
| 19 pending | |
| 19 failing | |
| 1) XCUITestDriver - element(s) | |
| interactions | |
| text fields | |
| "before each" hook: callee$3$0 for "should type in the text field": |
Espresso and Appium are both automated UI testing frameworks but they work in different ways. There are use-cases where Espresso is the more suitable choice and there are use-cases where Appium is the more suitable choice.
The primary difference between the two is that Appium is a purely black box testing framework and Espresso is not black-box or white-box, but what they call a "grey box" testing framework (this will be explained further).
Appium tests the actual Android application. It takes the application apk and runs UI tests on them without access to any of the internals of the application. An Appium test knows nothing about "Activities", "Broadcast Services", "Intents", etc... The tests have the same access privileges to an application that a user has and thus the tests simulate the usage of an app the way that a user would actually use the app.
Espresso, on the other hand, is a Java framework that is installed with