Screenshot capture
Thescreenshot action captures the current screen and writes a PNG file.
Returned metadata includes:
labelfilepathwidthheight
- if a path is provided directly, visor writes to that path
- if no path is provided, visor writes
<label>.png - parent directories are created automatically
- real runtime uses Appium screenshot persistence
- mock runtime writes a valid 1x1 transparent PNG
UI source capture
Thesource action captures the current UI hierarchy and writes an XML file.
Returned metadata includes:
labelfilepathformat, which isxmlbytes
- if a path is provided directly, visor writes to that path
- if no path is provided, visor writes
<label>.xml - parent directories are created automatically
- real runtime writes the current Appium
page_source - mock runtime writes a minimal XML hierarchy
Automatic paths during scenario runs
Whenscreenshot and source are executed inside a scenario run, visor injects deterministic per-run paths before the adapter call.
Injected directories:
- screenshots go under
<output>/<run-id>/screenshots/ - UI sources go under
<output>/<run-id>/sources/
<output>/<run-id>/screenshots/app-opened.png<output>/<run-id>/sources/counter-after-increment-ui.xml
Artifact collection
During a scenario run, visor records screenshot and source paths as run artifacts. Later, the report writer copies these artifacts into the final report structure and renames them with an ordered numeric prefix. Example final names:001-app-opened.png002-counter-after-increment-ui.xml
Why both screenshot and source matter
The two capture types answer different questions.| Evidence type | Best for |
|---|---|
| Screenshot | Visual layout, styling, and state visible on screen |
| UI source | Structure, text values, identifiers, and machine comparison |
Recommended labeling practice
Labels are not required in every case, but they are strongly recommended. Good labels make artifacts easier to compare over time. Examples of useful labels:before-loginafter-logincart-openedcheckout-formconfirmation-screen