skip to content

Why can Appium Inspector show a locksmith call-out element that your test's find call cannot match?

level: middleimportance: must knowfreq 58%

answer

  1. a photograph, not a window
  2. refresh happens on request
  3. the capture is bounded
  4. depth cap per driver
  5. your find takes its own capture

basics

~20 s

The Inspector's tree is a page-source snapshot from your last refresh, not a live view, and it is depth-capped by snapshotMaxDepth. Your test's find runs against its own fresh capture, so the two can honestly disagree.

solid answer

~40 s

Two different captures are involved. The Inspector asked for the page source when you last pressed refresh and has been drawing that answer ever since; your test's find makes the driver take its own capture at the instant of the call. Between the two, the locksmith call-out app may have finished an animation, loaded the job list or rebuilt the screen — so the tree can hold a node that no longer exists. The other cause is truncation: the serialised hierarchy is depth-capped, by the `snapshotMaxDepth` setting of the UiAutomator2 driver on Android and of the XCUITest driver on Apple platforms, with XCUITest adding `snapshotMaxChildren` per node. Refresh first to rule out staleness, then raise the cap to test for truncation.

code

json · 9 lines
json
{
  "capabilities": {
    "alwaysMatch": {
      "platformName": "Android",
      "appium:automationName": "UiAutomator2",
      "appium:settings[snapshotMaxDepth]": 100
    }
  }
}

go deeper

for a junior

Know that the Inspector's tree is a snapshot from your last refresh rather than a live view, and that pressing refresh is what updates it. Do not treat it as the app itself.

for a middle

Explain both causes of a disagreement: the capture is old, or the capture was truncated by a depth cap. Name the setting per driver and say why the shared name is two separate mechanisms.

for a senior

Separate staleness from truncation before you change anything, and be ready to say why a locator confirmed only in the Inspector is not yet confirmed for the suite that has to use it.

for a principal

Own the standard. Decide what counts as proof that a locator works, and stop a tool's documentation from becoming a source of settings the drivers no longer read.

## Two trees, two moments The Inspector's tree and your test's find never look at the same thing. The Inspector asked for the page source when you last pressed refresh and has been drawing that answer ever since. Your test's find makes the driver take its own capture, at the instant of the call. Between the two captures the locksmith call-out app was free to finish an animation, load the job list, dismiss a toast or rebuild a screen. Nothing has gone wrong when they disagree: you compared two photographs taken minutes apart and expected them to match. That is the first and most common answer, and it is worth saying plainly — the Inspector's tree is not a window onto the app. It is a photograph of what the driver said a moment ago. ## Refresh happens on request Nothing in the Inspector polls. The tree changes when you ask it to change, and the screenshot beside it was taken by the same refresh, so at least the two panes agree with each other. What they do not do is follow the device. If you drive the app from the Inspector's own controls, from a paused test, or by hand on the device, both panes keep showing the previous world until you refresh again. The practical consequences: - An element you can see on the device but not in the tree may simply postdate your last refresh - An element in the tree that a find cannot match may have been gone before the find ran - Two consecutive refreshes on a busy screen can legitimately return different trees - The suggested-locator timings belong to the capture they were measured on, not to the screen in front of you now ## The tree is bounded, and the bound is per-driver Even a fresh capture is not the whole hierarchy. The drivers cap what they serialise, and the cap the Inspector's tree inherits is the same one your find is subject to. | Where | What bounds it | Kind | |---|---|---| | Android, UiAutomator2 driver | `snapshotMaxDepth` | A driver setting | | Apple platforms, XCUITest driver | `snapshotMaxDepth` | A driver setting | | Apple platforms, XCUITest driver | `snapshotMaxChildren` | An additional per-node cap | The name is shared across the two platforms and the mechanism behind it belongs to each driver separately, so name the driver you mean when you tune it. A deeply nested control — a custom keypad several layers inside a scroll container on a job screen — can sit below the cap, and then it exists on the device, exists for the user, and does not exist in the tree at all. ## Telling staleness from truncation The two causes want different fixes, so separate them before changing anything: 1. Refresh without touching the app, and look again. If the element appears, it was staleness and there is nothing to configure. 2. If it is still missing, walk that branch down to the deepest node the Inspector will show. A branch that ends abruptly at a container rather than at a leaf is the shape of a truncated capture. 3. Raise the depth cap for the session — the UiAutomator2 setting on Android, the XCUITest one on Apple platforms — and capture again. If the element now appears, it was truncation. 4. If it appears in neither case, the element is not in the driver's account of the app at all, and no Inspector setting will conjure it. ## One setting not to reach for The Inspector's own documentation still names `customSnapshotTimeout`, and that setting is gone: WebDriverAgent removed it along with the custom snapshotting logic it belonged to, and the XCUITest driver dropped its own copy when it took that WebDriverAgent upgrade. It survives in a stale type declaration and in prose. Setting it changes nothing, and an hour spent tuning a value no driver reads is an hour not spent on the real cause. Treat it as a reminder that a tool's documentation and a driver's behaviour are two different artefacts, and only one of them answers your find. ## What to carry into the interview The point of the leaf is that the Inspector is a debugging aid whose output is a bounded snapshot, and that treating it as ground truth is the mistake interviewers are probing for. Confirm what exists in the tree, then confirm the runner can reach it from the state the suite actually arrives in. The tree is evidence; a passing find is the proof.

  • You raise the depth cap and the element still does not appear — what now?
    Then it is not truncation. Either the capture predates the element, so refresh and look again, or the driver's account of the app genuinely does not contain it. At that point the question moves off the Inspector's configuration and onto what the driver can see of the app at all.
  • Why is a locator that the Inspector's suggestion table timed still not proven for your suite?
    Because it was measured against one capture of one screen, under Inspector load, at a moment your test will never reproduce exactly. It is evidence that the element was findable then. The proof is the runner finding it, from the state the suite actually arrives in.

The tree is a photograph of the screen, not a window onto it. Everything you are reading is exactly as old as the last time you pressed refresh.

saying these in an interview costs you the question

  • Treats the Inspector's tree as a live view of the device
  • Says a missing element proves the driver cannot see it
  • Ignores the depth cap and blames the locator strategy
  • Sets customSnapshotTimeout because Inspector documentation names it
  • Assumes the Inspector's tree and the find share one capture