Argent QA E2e
Write repeatable QA regression e2e tests from test cases, tickets, or acceptance criteria. Use when the user asks to write, automate, or generate an e2e test or preserve an automated regression scenario, with deterministic setup, stable targets, executable structural or visual evidence, and two consecutive full passes. For one-off UI checks or replayable paths without acceptance criteria, use argent-test-ui-flow or argent-create-e2e. Supports iOS, Android, Chromium, and Vega (Fire TV), where recorded tv-remote steps replace touch directives. Apple TV and Android TV are unsupported; use argent-tv-interact there and report the limitation.
- Skill ID
- software-mansion/argent/argent-qa-e2e
- Publisher
- software-mansion
- Repository
- argent
- Installs
- 323
- Files
- 1
- Synced
- Oct 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
software-mansion/argent/argent-qa-e2eInstalls these files- SKILL.md
What this skill tells the agent
Create a QA regression e2e test
Load argent-create-e2e as the authoring engine. Follow its required references for recorder syntax, selectors, polish, platform exceptions, and repair. This skill adds the QA contract and completion gate.
Vega supports every item below: launch: { vega: ... }, await:/assert: selectors, snapshot:, and idle all run there. Only the touch directives are missing, because Vega is remote-driven. Navigate with recorded tool: tv-remote steps and type with tool: keyboard, which leaves item 5 with nothing to govern. A D-pad path is relative to where focus already is, so gate every move with item 4's identity check rather than assuming the cursor landed. Read argent-tv-interact for focus reading and remote navigation.
Apple TV and Android TV are out of scope. The runner does not reject touch directives there, so they fail at the gesture layer instead of with authoring guidance. Use argent-tv-interact and report the limitation.
Physical iPhones run QA e2e tests, with three hardware limits: replay never auto-binds a phone, so pass its udid as device (CLI --device) and keep it connected; pinch/rotate steps fail there like the live tools, so drive the app's own zoom UI instead; the runner tree is the describe tree (same ids and roles), so a selector authored on a simulator can miss there. Read argent-ios-device-interact for the app-scoped contract before recording.
Definition of done
A QA e2e test is complete only when:
- The first step that is not
echo:orscript:islaunch:. In-test setup proves a deterministic data baseline. Repeated runs do not accumulate artifacts or require manual cleanup. - The first walkthrough recorded every action and live structural check. Only the three documented polish insertions are unrecorded.
- Every requirement maps to a hard
await:,assert:, or reviewedsnapshot:. Echoes and screenshots are not verdicts. A negative check needs the same stable selector established as visible earlier. - Every screen change has destination identity followed by
idlereadiness. - Targets satisfy the stable-selector and coordinate-fallback rules. QA keeps coordinates only for genuinely unlabeled targets. Vacuous on Vega, which has no coordinate targets.
- The unchanged YAML passes twice with the same runner. Pass 1 starts with fresh mobile Argent services, and pass 2 follows immediately.
1. Define the test contract
Before touching the app, write a compact table. Restate it in the final report. Include:
- App, platform, and named start state.
- Ordered user actions.
- One row for each expected outcome, persistence rule, or absence claim.
- Stable executable evidence for each row.
- Required data and side effects.
Use structural checks for semantic state, snapshots for pixels, and both for mixed requirements. One behavioral scenario becomes one qa-<area>-<behavior> e2e test.
Do not invent a material value or weaken ambiguity. Choose the strongest UI-verifiable reading and report it. Ask when the choice changes test meaning.
Make repeated runs deterministic:
- Inspect the required baseline without mutation.
- If the account is dirty, record a safe reset or seed e2e test. Alternatively, include safe normalization in setup.
- After setup navigation, echo the named baseline and hard-check it before the first scenario mutation. Use
assert:or a destinationawait:that fully proves the baseline. - Prefer to restore the baseline at the end.
An e2e test has two fixture mechanisms:
run:replays a separately recorded reset or seed e2e test.script:runs requested local setup or cleanup. Record it withe2e-add-scriptwhere it belongs in the walkthrough.
Ask before cleanup that creates or deletes meaningful user data outside the request.
Compact example
Ticket: select Dark in Settings. Verify Dark is selected, Light is absent, and the screen renders in dark mode.
| Contract row | Action | Evidence | State effect |
|---|---|---|---|
| Signed-in Home | Launch | await: { visible: { id: home-screen } }, then await: { idle: true } | Existing account |
| Open Settings | Tap settings-tab | await: { visible: { id: settings-screen } }, then await: { idle: true } | None |
| Prove Light selected | Inspect Settings | assert: { visible: { id: theme-light-selected } } | Fails if already Dark |
| Prove Dark selected | Tap theme-dark-option | await: { visible: { id: theme-dark-selected } } | Theme becomes Dark |
| Prove Light absent | Inspect settled screen | assert: { hidden: { id: theme-light-selected } } | None |
| Verify dark rendering | Inspect settled screen | snapshot: settings-dark | None |
| Restore baseline | Tap theme-light-option | await: { visible: { id: theme-light-selected } } | Next run starts clean |
The initial Light check establishes the selector used by the later hidden check. The final restore makes pass 2 independent.
2. Record the scenario
Follow argent-create-e2e's start order and live-authoring cycle. Record each structural contract check when its state appears.
A snapshot has no recorder form. Inspect its stable state during the walkthrough, then add the planned snapshot during polish. If direct recovery changes state, re-record the affected behavior. A recovered walkthrough is not proof.
3. Make evidence discriminating
- State change: prove the new state and the old state's absence when both can otherwise match.
- Cancel/persistence: cross the commit boundary. After cancel or save, leave, re-enter, then verify the stored state: unchanged after cancel or updated after save.
- Absence: prove the containing screen and record the same stable selector as
visible, then the action, thenhidden. Do not add an unestablishedhiddencheck only to strengthen a positive baseline. In a collection, viewport absence is not global absence. Use fixed seeded position, count, empty state, or other collection-wide evidence. - Overlays: use the create-e2e obscured-target procedure.
- Repeated controls: prefer an id. Otherwise use YAML-only
withinwith a stable container. Usetext.into prove rendered membership inside that container. - Dynamic content: assert controlled state or stable app chrome. Use anchored structure for unavoidable dynamic values and disclose the dependency.
- Visual state: snapshot only a correct, settled, deterministic screen. Use full screen for global changes and
cropOnfor one component.
Never put acceptance evidence inside when:. Use when: only for optional setup that reconverges to the required path.
4. Finish and audit
Complete the create-e2e polish and blocking audit. Then:
- Map every contract row to an executed action or hard check.
- Build a navigation table with one row per screen change, naming both the identity gate and the readiness gate. A row missing either is a blocking defect.
- Confirm setup and end state permit an immediate second run.
| Action | Destination | Identity | Readiness |
|---|---|---|---|
Tap settings-tab | Settings | settings-screen visible | idle |
More from software-mansion
Use this skill in a project
Open any RiverX project, search the Skills panel for software-mansion/argent/argent-qa-e2e, and install it in one click.
