Skip to main content
Selenium and Appium suites carry heavy framework overhead: driver setup, capability negotiation, explicit waits, page objects, and a grid. In Momentic, all of that collapses into *.test.yaml files plus momentic.config.yaml. You port flows, not plumbing.

Before and after

A representative Selenium test (Java/TestNG, but the shape is the same in Python or JavaScript):
CheckoutTest.java
The same test in Momentic:
checkout.test.yaml
Every wait.until(...) disappears: Momentic steps poll until their target or condition resolves, up to a per-step timeout. Every selector becomes either a natural-language target or a CSS string inside the step.

API mapping

Page objects and helpers

The Page Object Model maps to modules. Each LoginPage.java becomes modules/log-in.module.yaml with parameters for its inputs:
log-in.module.yaml
Call it from before: or steps: with inputs. Callers pass concrete values or env references, mirroring constructor-injected page objects.

What keeps working unchanged

  • Your test data and seed APIs. javascript steps run Node with axios, pg, faker, and child_process. Existing seed endpoints and database helpers port without redesign.
  • Appium-specific glue. On mobile, the appium step executes arbitrary mobile: scripts (mobile: shell, mobile: deepLink, gestures that no preset step covers). Port the common paths to natural-language steps and keep appium for the edge cases.
  • Your CI. Replace the grid and driver setup with npx momentic install-browsers chromium (web) or a hosted browser/emulator. See Hosted test environments.

What does not map

  • Driver lifecycle control. There is no WebDriver object to hold or pass. You cannot run two driver sessions in one test; parallel testing is per-test parallelism, not multi-session choreography.
  • XPath/CSS depth. Selectors still work as targets, but the intended use is natural language. Complex XPath logic has no equivalent: express the element by what it looks like, and let step caching keep it fast.
  • ExpectedConditions variety. Momentic covers the common conditions (visible, text, URL, attribute) but not exotic ones like elementSelectionStateToBe. A javascript step in the browser can check anything the DOM exposes.
  • Real devices. Remote execution covers Android emulators and iOS simulators, not physical device farms. Keep a device-farm runner for the tests that need hardware.
  • Non-HTTP protocols. Selenium suites that drive WebDriver against non-browser targets do not map; Momentic tests browsers and mobile apps.

Incremental strategy

  1. Start on the suite’s worst offender: the flakiest flow, the one with the most ExpectedConditions. Port it to a single *.test.yaml and run it daily for a week. This is the fastest way to see whether Momentic’s waiting model holds up on your app.
  2. Convert page objects to modules as you go; the second test on the same flow is nearly free.
  3. For mobile, run a local emulator first (momentic-mobile run against your .apk/.app), then switch individual tests to remote instances through the Region selector.
  4. Run Selenium and Momentic side by side in CI. Label ported tests and gate on them once they stabilize.
  5. Retire the grid last: after the browser coverage you need is confirmed, not when the first suite passes.

Porting at scale with a coding agent

Hand the port to your coding agent with a prompt like: