Skip to content
verikun

Your first test

This walks from a connected device to an HTML report you can open in a browser. It assumes you have finished Installation.

1. Check the device

Section titled “1. Check the device”
Terminal window
vk doctor --fix
vk devices

--fix prepares the device for testing (animations off, a sane display timeout, and more); a physical device must be named with --device. Animations are the single biggest cause of a UI dump that reads a screen mid-transition, so this is worth doing once per device.

If vk devices lists more than one, pick one for the rest of this page:

Terminal window
export VERIKUN_DEVICE=emulator-5554     # or a phone serial from `vk devices`

2. Launch the app under test

Section titled “2. Launch the app under test”
Terminal window
vk launch com.example.app

launch restarts by default — it force-stops the app first, so you begin from a cold screen rather than wherever a previous session left off. Add --clear to also wipe local data (login, preferences, caches) for a fresh-install state.

3. Look at the screen

Section titled “3. Look at the screen”

This is the command that matters most:

Terminal window
vk ui
[0] TextView "Welcome back" (540,360)
[1] EditText @email_input (540,720) focused
[2] EditText @password_input (540,860) pwd
[3] Button "Sign in" @sign_in_btn (540,1020) tap
[4] TextView "Forgot password?" @forgot (540,1140) tap

Read that as: index, element type, visible text, @resource-id, centre coordinates, and flags (tap = clickable, pwd = a password field, focused, offscreen).

Reach for this textual snapshot instead of a screenshot whenever you can: it is a fraction of the tokens, and it gives you the identifiers to act on — see Be frugal.

Useful variants:

Terminal window
vk ui --all      # keep layout nodes too, not just interactive/labeled ones
vk ui --tree     # indent by nesting, to understand structure
vk ui --json     # structured, for scripting

4. Act on it

Section titled “4. Act on it”

Use the identifiers from step 3, not coordinates:

Terminal window
vk text @email_input "user@example.com"
vk text @password_input "hunter2" --enter

Two things happen automatically here, and they are why flows need so few explicit waits:

  • Auto-wait — the field lookup re-polls the screen for up to 5 seconds before giving up, so a form that is still animating in is fine.
  • Auto-scroll — if the field is below the fold, text scrolls it into view first. “Scroll down and tap X” is just vk tap X.

5. Assert the result

Section titled “5. Assert the result”

An assert is what makes this a test rather than a macro:

Terminal window
vk assert text:"Welcome back" --wait 8s

Exit 0 means it passed. Exit 1 means it failed. That is the whole contract, and it is what CI reads — see Exit codes.

assert polls the whole predicate, not just presence, so --gone waits for something to disappear:

Terminal window
vk assert @loading_spinner --gone --wait 15s

6. Produce a report

Section titled “6. Produce a report”

You did not have to start a test run — one auto-started on your first action. Close it:

Terminal window
vk run archive smoke

That writes to ./.verikun/runs/<id>/:

File What it is
report.html A self-contained report: every step, the identifier each selector resolved through, screenshots, and the screen + hierarchy of any failed step
report.xml JUnit — drops straight into CI
run.json The raw recording
artifacts/logcat.txt Device log for the run window

Open report.html in a browser.

7. Put it in one file

Section titled “7. Put it in one file”

Running one vk per step is fine while exploring. Once the flow is known, put it in a batch file so it runs in a single process:

Terminal window
vk batch <<'EOF'
launch com.example.app
text @email_input "user@example.com"
text @password_input "hunter2" --enter
assert text:"Welcome back" --wait 8s
run archive smoke
EOF

Each line records as its own step, exactly as if you had typed it, and the batch stops at the first failure.

Where to go next

Section titled “Where to go next”