How would you budget xpath use in an Appium tram fare-inspection suite spanning Android and iOS?

## Why one ceiling cannot serve both lanes An `xpath` budget is a rule about how much serialisation a run is allowed to pay for. The trouble is that the unit being budgeted does not cost the same on both platforms. On Android the UiAutomator2 driver's on-device server builds its XML document from the accessibility node tree. On iOS `WebDriverAgent` builds its own from an XCTest element snapshot, and the XCUITest driver's docs warn that the resulting `xpath` lookup can run up to ten times slower than an `-ios predicate string` or `-ios class chain` one. A single blanket rule therefore either over-constrains the Android lane or under-constrains the iOS one. Neither is a budget; both are a guess wearing a budget's clothes. ## What to count Count **serialisations per case, per platform** - not expressions, not characters, not how many distinct strategies the suite uses. - Every `xpath` find is one document build, on both platforms. - One `findElements` call that returns forty fare-inspection ticket rows is one build; forty single finds are forty. - An element-scoped find is still a build, and `limitXPathContextScope` decides whether it is matched against the element's subtree or the whole page source. - A find that fails and is retried is another build, so retries inflate the count silently. That count is what scales with the app, and it is the only thing a budget can meaningfully constrain. ## Making the budget observable A budget that lives in a review comment decays. A budget that lives in a measurement does not. 1. **Time the find commands.** The Appium server log records commands, so find durations are visible per platform without instrumenting the tests themselves. 2. **Baseline per screen, per lane.** The cost tracks how much tree the screen carries, so the same expression against a fuller ticket list is a different number in both lanes. 3. **Re-measure when a surface grows.** A screen that gains rows gets more expensive with no locator change at all, which is exactly the failure mode a static rule cannot see. 4. **Treat a find-duration regression as a signal.** It usually means the tree grew rather than that anyone touched the locator. ## Where xpath still earns its cost Banning it outright is as unmeasured as ignoring it. `xpath` is declared by the UiAutomator2 driver on Android and by the XCUITest driver on iOS, and it is the strategy most likely to express one intent in both lanes. It is worth its price when: - the find happens once per case rather than once per row; - the screen is shallow, so the document being built is small; - the alternative is two platform-specific locators whose drift would cost more to maintain than the extra run time costs; - and no cheaper same-lane strategy expresses the intent - `id`, `accessibility id` or `-android uiautomator` on Android, `-ios predicate string` or `-ios class chain` on iOS. ## The two lanes' cost profile | | Android, UiAutomator2 driver | iOS, XCUITest driver | |---|---|---| | Document source | the accessibility node tree | an XCTest element snapshot | | Dialect | XPath 2, or XPath 1 with `enforceXPath1` | XPath 1.0, no switch | | Documented relative cost | slower than the on-device strategies | up to ten times an `-ios class chain` lookup | | Realistic per-case ceiling | higher | lower | | Cheaper alternatives | `id`, `accessibility id`, `-android uiautomator` | `-ios predicate string`, `-ios class chain` | ## Keeping the two-locator decision honest The real trade-off a budget encodes is not `xpath` against another strategy; it is **one portable expression against two maintained ones**. A single expression that works in both lanes is one thing to change when the fare-inspection screen changes. Two per-platform locators run faster and are twice the surface to keep in step - and they drift silently, because the Android one gets updated in the pull request that changed the Android layout and the iOS one does not. A budget that counts only run time pushes a suite towards that drift; a budget that acknowledges both costs will spend `xpath` deliberately on the low-frequency finds and put per-platform strategies on the hot ones. ## What a budget is not - It is not a style rule. Nobody can tell from reading an expression what it costs; only the screen it runs against can say. - It is not a one-time exercise. The number moves with the app, independently, on both platforms. - It is not satisfied by shortening expressions. The document build dominates the evaluation on Android and on iOS alike. - It is not a substitute for measuring the lane that actually hurts. If iOS is the one stalling, the Android numbers will not tell you what ceiling it needs.