Skip to main content
Use this journey when an ad hoc device run found a valuable path and you want to preserve it as a repeatable test.

​
Goal

Turn one exploratory run into:
  1. A named local YAML test
  2. A pushed test on Revyl
  3. A runnable regression check

​
1. Run focused exploration

Start from a live dev session: 
revyl dev
Prompt the agent with a concrete objective: 
Use Revyl MCP tools only.
Goal: complete bypass login and land on the home feed.
Use screenshot -> observe -> action -> screenshot verification on every step.
Record the exact successful sequence.

​
2. Capture a conversion artifact

Ask the agent to produce a compact artifact:
  1. Test name in kebab-case (for example bypass-login-home)
  2. Preconditions (build, account state, environment)
  3. Ordered steps (actions only)
  4. Validations (visible outcomes only)
  5. Variables needed (credentials, dynamic values)

​
3. Create the test shell

Use standard test commands: 
revyl test create bypass-login-home --platform ios
revyl test open bypass-login-home
Or stay in dev namespace: 
revyl dev test create bypass-login-home --platform ios
revyl dev test open bypass-login-home

​
4. Convert ad hoc flow into robust assertions

When translating steps:
  1. Keep one action per instruction.
  2. Keep validations separate from actions.
  3. Validate outcomes, not transient loading states.
  4. Use variables for credentials and dynamic values.

​
5. Push and execute on the platform

revyl test push bypass-login-home --force
revyl test run bypass-login-home
If this is a key user path, add it to a workflow so it runs automatically with related tests.

​
6. Definition of done

Your conversion is done when:
  1. The test passes on correct app behavior.
  2. The test fails on the intended regression.
  3. The scenario is understandable by another engineer from YAML + test name alone.

​
Prompt you can reuse every time

Take the successful ad hoc session and convert it into a production-ready Revyl test.
Output:
1) test name,
2) YAML-ready step list (instructions/validations),
3) variables required,
4) expected pass criteria.
Favor stable validations over overly specific UI details.