Skip to main content
A step is one unit of work in a test or module. Steps run in order inside the before, steps, and after arrays. They can interact with your product, verify or extract state, choose or repeat a path, call a reusable module, or run custom code. Momentic supports exact, reviewable sequences and goal-driven execution in the same test: See File format for the top-level YAML structure.

​
Preset steps

A preset step performs one operation at a known point in the test. Use preset steps when the interaction or check should remain explicit. A preset step can still use AI. For example, Momentic can resolve a natural-language target, evaluate an assertion, or extract structured data with AI. The configured operation and its position in the sequence remain fixed. Other preset steps, such as navigating to a URL or waiting for a duration, are fully deterministic. Preset steps cover:
  • Interactions such as clicking, typing, tapping, swiping, and scrolling.
  • Browser navigation, app lifecycle, device controls, and waits.
  • Assertions, element checks, visual comparisons, and data extraction.
  • Network requests, route mocking, browser state, and files.
  • JavaScript and Appium integration for custom behavior.
See the Web steps reference for every available preset step.

​
Targets

Interactive preset steps identify the element they act on. Natural-language targets keep a step readable and let Momentic resolve the element from its text, appearance, accessibility attributes, and surrounding structure. Successful resolutions are cached for later runs. The target field depends on the operation. Common keys include on, into, from, and that; each preset step’s reference lists the fields it accepts.
Web preset steps accept natural language, CSS or XPath selectors, and absolute coordinates.

​
Shorthand and detailed syntax

Use the shorthand form when a preset step only needs its primary value. Use the detailed form when it needs more options:
Preset steps without a value can use a bare alias, such as - refresh on web or - killApp on mobile. In the detailed form, place every option under the preset step key. The shorthand form cannot have additional options.

​
Assertions and extraction

Use assert for a condition that requires AI evaluation, extract to read structured data with AI, and checkElement<...> for a specific element state or value.
See Writing assertions for choosing the right assertion type and defining durable outcomes.

​
AI actions

An AI action takes a natural-language goal instead of a fixed interaction. At runtime, the agent observes the current page or screen and executes the steps needed to reach that goal. Write the goal directly for the common case:
Use act: when the action needs a precondition, postcondition, cache control, or other options:
See Goal-based testing for writing bounded goals, postconditions, and cache guidance.

​
Control flow

Control-flow steps decide which nested steps run. Use if when a path depends on current product state and while when the same work must repeat until a condition changes or a limit is reached.

​
Conditionals

A conditional contains one condition and a then list. The condition can be an inline assert, an element or screen check, or a javascript expression.
There is no else branch. Use a separate conditional when another path is required.

​
While loops

A while loop contains a do list and at least one loop control: a condition or maxIterations. The condition is evaluated before each iteration.
Nested steps share the test’s env, so a value written with saveAs is available to the next condition check. Use only maxIterations when the loop should repeat a fixed number of times.

​
Module calls

A module call inserts a reusable sequence of preset steps and AI actions into a test. Reference the module relative to the file containing the call:
When a module takes no inputs, write its path directly:
Module input strings are JavaScript expressions, not mustache templates. Use { string: ... } for a literal value and { javascript: ... } for a script. See Modules for parameters, defaults, and caching.

​
Code integration

JavaScript and Appium are preset steps that extend Momentic when a built-in operation does not express the work. Use them for test data, APIs, databases, application state, or platform APIs. Keep user interactions in the built-in preset steps so they retain Momentic’s targeting, waiting, caching, and traces.
Web JavaScript runs in a sandboxed Node environment by default. Set environment: browser when the code needs window, document, or page state.
See JavaScript for runtimes, utilities, and variables.

​
Shared syntax

Detailed preset steps and AI actions keep their options under the step key. Common options include retries, skipped, comment, and saveAs. saveAs writes a returned value to env.<NAME> for later steps.

​
Variables and templating

String fields can include {{ expression }} templates evaluated against the test’s env map. JavaScript source reads values directly as env.NAME without mustache syntax. See Variables for sources, scope, and module parameters.

​
File references

Relative paths resolve from the YAML file containing the step. A path inside a module is relative to that module, not the test that calls it or the project root.

​
Durations

Durations in the simplified YAML format use milliseconds:

​
Authoring references

Use the generated V2 format reference when you or a coding agent need exact YAML shapes, compatibility versions, or less common fields. When authoring through the MCP server, read the platform-specific Step Authoring Guide returned by session start. It covers the CLI-style step arguments accepted by MCP tools, which differ from the on-disk YAML shown here.