Skip to main content
Regression testing reruns your existing test suite on every change so you catch when a flow that used to work breaks. Reach for it once you have flows worth keeping: run the whole test suite in CI on each commit or pull request and treat a failure as a release blocker. Because tests are defined in natural language, a cosmetic UI change does not fail a test that still works, so a failure means a real regression, not a moved button. 
npx momentic run --upload-results

​
When to use it

  • You ship often enough that re-verifying every flow by hand before each release is not realistic.
  • A change in one area can break something far from the edit: a shared component, an API contract, a dependency bump.
  • You already spend engineer time on manual regression passes, or you learn about regressions from users instead of CI.
It is less useful before the product has flows stable enough to keep. If your core flows still change weekly, start with a few smoke tests and grow coverage as flows settle.

​
What to cover first

Prioritize by blast radius, not by what is easiest to automate. You do not need full coverage on day one to get value.
  • Revenue and retention paths first: sign-up, checkout, the primary action your product exists to do.
  • Flows that have regressed before.
  • Flows that exercise shared code many features depend on.
Add breadth over time, and let the explore agent propose tests for journeys you have not covered yet.

​
How it works

  • Author tests once as natural-language steps. See the web, iOS, and Android quickstarts.
  • Auto-heal repairs a test mid-run when the UI changed, so routine UI edits do not turn into failing builds to triage.
  • Reuse shared setup (login, seeding) with modules so one change updates every test that depends on it.

​
Run it in CI

1

Build a baseline test suite

Cover your highest-priority flows and confirm they pass locally. Start from the web, iOS, or Android quickstart.
2

Run the tests on every change

Add Momentic to your pipeline so the test suite runs on each commit or pull request. See GitHub Actions, GitLab CI, or custom setups for other providers.
3

Triage failures

When a run fails, read the trace and screenshots in results. Isolate unstable tests with quarantine so one flaky test does not block the rest.

​
Keeping the test suite healthy

A regression test suite earns its place only if the team trusts a failure. Budget for upkeep, not just authoring:
  • Quarantine flaky tests instead of disabling them. Quarantined tests still run but do not fail the build, so you keep the signal while you fix the test, then promote it back out of quarantine.
  • Keep runs fast as the test suite grows by sharding across CI machines with --shard-count and --shard-index rather than dropping coverage.
  • Give flows clear ownership so a failure is triaged by someone with context, while the change that caused it is still fresh.

​
Notes

  • A failed run exits non-zero so CI blocks the merge. Quarantined tests are the exception and do not affect the exit code by default.

Explore agent

Find journeys a diff changed and author tests for the gaps.

Auto-healing

Repair tests automatically when the UI changes.

Run in CI/CD

Run the tests on every commit and pull request.

Quarantine

Isolate unstable tests without blocking the rest of the test suite.