Skip to main content
Mo tests a running application. You give it a target and a brief, and it plans the test cases, works through them, and reports the bugs it reproduced. Mo needs no test files and no code, so you can get coverage on a preview build, a release candidate, or an area nobody has tests for. Momentic’s test suite is the other half of the product: tests live in your repository and run in CI on every merge.
Mo drives the application through its interface. It does not read or change your product code, and it does not write Momentic test files.

​
Targets

A session tests one of these:
  • A web app at a URL, in a hosted browser. The URL can be a production site, a preview deployment, or a local build through a tunnel.
  • An iOS app, on a remote simulator.
  • An Android app, on a remote emulator.
For iOS and Android, Mo installs a build you uploaded to a channel and a tag, the same build a Momentic mobile test uses. See iOS app setup and Android emulators.

​
What a session produces

A session keeps one report. It holds:
  • Test cases, each with preconditions, an outline, and acceptance criteria.
  • A verdict per case: verified, issues found, or blocked, plus the coverage gaps Mo could not close.
  • Bugs, each with expected behavior, actual behavior, reproduction steps, and a recording of the failure.
See session reports for the fields, and triage for the decisions you make on a bug.

​
The agents in a session

A session has a session agent and its sub-agents. Each role has one job: The reproducer keeps false positives out of the report. It gets no browser state and no fixtures from the agent that saw the problem. It builds its own setup, walks the flow from the beginning, and records the failure. A suspected bug that it cannot reproduce never reaches the report.

​
Parallel agents

Every sub-agent gets its own browser, simulator, or emulator, so cases are checked at the same time rather than one after another. A session can run a hundred or more at once. The session settings let you raise the number for a session, up to the limit of your plan.

​
Limits

A web session runs a browser in a hosted sandbox, so it cannot reach the device or the operating system behind the page: no microphone, no print dialog, no link into a mail app. Mo records the limit as a gap in the report instead of reporting a bug it cannot verify. One session tests one target. To cover web, iOS, and Android, start a session for each.

​
Not available yet

  • Pulling your repository and running the application itself, so Mo does its own setup and teardown in the codebase.
  • Delivery by Slack or email.
  • Sharing a report by public URL.

​
Next

Quickstart

Start your first session, read the report, and triage what it found.

Why Mo

How a session differs from your coding agent driving a browser.

Write a good brief

Define the target, scope, accounts, test data, and prohibited actions.

Run a session

Sign-in, test data, schedules, and session timing.