DEV Community: Wei-Wei Wu

Mobile MCP servers: set up Appium MCP, Maestro MCP and mobile-mcp

Wei-Wei Wu — Tue, 03 Nov 2026 16:00:00 +0000

Originally published on the Momentic blog.

TL;DR

mobile-mcp lets a coding agent inspect and control a mobile app during a live session. Reach for it when you need to explore the UI.
Appium MCP gives the agent access through an Appium session. Reach for it when your mobile setup already uses Appium drivers.
Maestro MCP lets the agent work with Maestro’s mobile testing tools. Reach for it when you already use Maestro flows.
All three can help an agent inspect and drive an app, but an MCP session alone does not leave behind a test that runs in CI.
For a versioned test, use Momentic’s MCP server to write and run YAML tests. Install the mobile skills with npx momentic-mobile skills --yes.

Appium MCP, Maestro MCP and mobile-mcp compared

All three run as local stdio servers that your coding agent starts with one command. They differ in what they drive and what they leave behind.

Server	Install	Platforms and targets	What the agent works with	Leaves a test behind?
mobile-mcp	npx -y @mobilenext/mobile-mcp@latest	iOS and Android: simulators, emulators and real devices	The native accessibility tree, with screenshots and coordinates as a fallback	No. The session lives in the agent's conversation
Appium MCP	npx -y appium-mcp@latest	Android (UiAutomator2) and iOS (XCUITest): simulators, emulators and real devices	An Appium session: find elements, tap, type, gestures, screenshots	It can generate Java/TestNG test code from a description
Maestro MCP	maestro mcp (needs the Maestro CLI)	iOS and Android apps, plus web	Maestro commands, so the agent can write, run and debug flows	Yes, when the agent saves the flow as a YAML file

Pick the one that matches the tooling you already run. If your team has Appium capabilities and drivers set up, Appium MCP reuses them. If you write Maestro flows, Maestro MCP lets the agent write more of them. If you want an agent to poke at an app with no framework at all, mobile-mcp has the least setup.

Setting up mobile-mcp

Boot an iOS simulator (xcrun simctl boot "iPhone 16") or start an Android emulator first. The project's installer finds the MCP clients on your machine and configures them:

npx @mobilenext/mobile-mcp@latest install

To configure each client by hand:

# Claude Code
claude mcp add mobile-mcp -- npx -y @mobilenext/mobile-mcp@latest

# Codex
codex mcp add mobile-mcp npx "@mobilenext/mobile-mcp@latest"

For Cursor, add the server to ~/.cursor/mcp.json or a project-level .cursor/mcp.json:

{
  "mcpServers": {
    "mobile-mcp": {
      "command": "npx",
      "args": ["-y", "@mobilenext/mobile-mcp@latest"]
    }
  }
}

mobile-mcp drives the app from the native accessibility tree first, so the agent reads element labels instead of spending image tokens on screenshots. It falls back to a screenshot and coordinate taps when an element has no accessible label. It also installs, launches and terminates apps, opens deep links and records the screen.

Setting up Appium MCP

Appium MCP bundles the UiAutomator2 and XCUITest drivers for local sessions. You still need the platform toolchains: ANDROID_HOME, Java and the Android SDK tools for Android, and Xcode with an installed simulator for iOS (macOS only).

# Claude Code
claude mcp add appium-mcp -- npx -y appium-mcp@latest

For Cursor, and for other clients that take a JSON config:

{
  "mcpServers": {
    "appium-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["appium-mcp@latest"],
      "env": {
        "ANDROID_HOME": "/path/to/android/sdk",
        "CAPABILITIES_CONFIG": "/path/to/your/capabilities.json"
      }
    }
  }
}

For Codex, the same server goes in ~/.codex/config.toml:

[mcp_servers.appium-mcp]
command = "npx"
args = ["-y", "appium-mcp@latest"]
env = { ANDROID_HOME = "/path/to/android/sdk" }

CAPABILITIES_CONFIG points at a JSON file of Appium capabilities, such as platformName, appium:deviceName and appium:app. The agent opens a session with appium_session_management, then uses tools such as appium_find_element, appium_gesture and appium_set_value. For a device farm or CI, pass a remoteServerUrl and explicit capabilities when the session is created instead of using the local drivers.

Setting up Maestro MCP

Install the Maestro CLI first. The MCP server is a subcommand of it, so there is no separate package.

# Claude Code
claude mcp add maestro -- maestro mcp

# Codex
codex mcp add maestro -- maestro mcp

Or add it to ~/.codex/config.toml by hand:

[mcp_servers.maestro]
command = "maestro"
args = ["mcp"]

For Cursor, merge this into ~/.cursor/mcp.json:

{
  "mcpServers": {
    "maestro": {
      "command": "maestro",
      "args": ["mcp"]
    }
  }
}

This assumes maestro is on your PATH. If the client starts from a minimal shell, use the full path from which maestro. Maestro MCP is the only one of the three that writes into a test format you already run: when the agent saves its work as a flow file, maestro test can run it again in CI.

Where an MCP session stops and a repeatable test starts

A live MCP session can help a coding agent inspect a mobile app and try a user journey, but the session alone does not give CI a test to run. The agent’s observations and next steps remain in its conversation unless the agent writes them into a file. A PR cannot review or rerun a conversation as a test.

For example, an agent might open an order screen and confirm that the latest order appears. To check that behavior after every change, you need a saved test with an assertion and a repeatable run command. Appium and Maestro can support persistent tests, but access through their MCP servers does not, by itself, save the agent’s exploration as one.

Momentic’s MCP server gives a coding agent a way to write, run, and fix tests while keeping the test definition as YAML in your repository. Install the mobile skills and the MCP server for your agent:

npx momentic-mobile skills --yes
npx momentic-mobile install-mcp

The command equips the agent to work on mobile tests. The agent still needs to turn the behavior it explored into a YAML test and run it. Once you commit that file, reviewers can diff the test in a PR, and CI can invoke it without asking the agent to explore the app again. The MCP server handles the agent interaction. The test file and CI invocation make the check repeatable.

Running the resulting test in CI

Run npx momentic-mobile skills --yes in your project, then use your coding agent and the Momentic MCP server to write and run the mobile test. Review the resulting YAML test and commit it to your repository. CI needs that file, not the agent’s chat history.

Add a pull-request job that builds the app and runs the committed test with the Momentic CLI. Give the job the credentials and simulator or emulator access it needs, then make the job a required status check so a failed test blocks the merge. The CI job runs the committed tests with npx momentic-mobile run --upload-results, with MOMENTIC_API_KEY set as a CI secret. See the CLI reference for device and sharding flags.

Frequently asked questions

Can these servers use physical devices?

Appium can drive physical iOS and Android devices when you configure the appropriate drivers and devices. Maestro supports physical devices as well as simulators and emulators. Check the mobile-mcp project’s README before assuming its server supports your device setup. Momentic’s mobile testing uses simulators and emulators, not physical devices.

Can one MCP configuration drive both iOS and Android?

You can register one server, but that does not make both platforms ready to use. You still need the devices and platform-specific tooling that the server requires. With Appium, you also need the appropriate driver for each platform.

How is Momentic’s MCP server different?

The device-control servers let an agent interact with a running app. Momentic’s MCP server lets an agent write, run, and fix end-to-end tests that remain as YAML files in your repository. The separate npx momentic-mobile skills --yes command installs mobile testing skills. Check the Momentic documentation for the current setup.

Must I abandon an existing Appium or Maestro suite?

No. You can keep that suite in CI while adding Momentic tests for behavior you want to cover separately. Do not assume existing test files will run unchanged in Momentic.

Migrating from Selenium to Playwright: A Step-by-Step Guide

Wei-Wei Wu — Sat, 31 Oct 2026 09:54:45 +0000

Originally published on the Momentic blog.

Migrating from Selenium to Playwright takes 11 steps: audit the framework, pick a language, install Playwright, convert tests, replace wait strategies, rebuild page objects, simplify parallel runs, update CI/CD, migrate gradually, train the team, then adopt advanced features. To skip the rebuild, teams move straight to Momentic, where tests are plain-English YAML that coding agents write and maintain.

Tired of the constant workarounds needed to make Selenium work with modern web apps?

Thinking about all the hours the team could save* if only Selenium did X, Y, or Z better*?

Congratulations – you’ve reached the point where many engineering teams start to consider migrating from Selenium to Playwright. Here’s what you need to do, the challenges you should anticipate, and some alternative software suggestions.

One more path exists. Teams that move to Momentic skip the rebuild: tests are version-controlled YAML in your own repository, they self-heal when the UI changes, and Mo, an autonomous AI coworker, explores the app and reports bugs beyond your migrated coverage. The last section covers that option.

Why Migrate from Selenium to Playwright?

Teams migrate because Playwright executes tests faster, waits for elements automatically, handles modern web apps, runs tests in parallel natively, and needs fewer third-party integrations than Selenium.

In the case of Playwright and Selenium, it’s pretty clear that the efficiency gains you’ll get from Playwright far outweigh that risk. Here’s why:

Playwright Executes Tests Faster

Playwright runs tests faster thanks to its direct browser communication over WebSockets (no WebDriver layer).

Playwright Offers Built-In Auto-Waiting

Playwright automatically waits for elements to be actionable before testing. This means fewer flaky tests and less time spent coding complex workarounds – especially if you’re testing SPAs.

Playwright Handles Modern Apps Better

Selenium was released in 2004, Playwright in 2020. This means that Playwright is, naturally, better designed for modern testing needs – as well as SPAs, Playwright deals with shadow DOMs, network interception, and multiple browser contexts better than Selenium.

Playwright Offers Native Parallel Support

Playwright supports parallel testing out of the box. This offers a significantly easier and more efficient way of running parallel tests than Selenium, which relies on external tools.

Playwright Requires Fewer Third-Party Integrations

Playwright has a built-in test runner and reporting features, so you don’t need to rely on third-party tools for test retries, tracing, screenshots, or HTML reports.

How to Migrate from Selenium to Playwright In 11 Steps

The migration takes 11 steps, from auditing your Selenium framework to adopting Playwright's advanced features, and most teams run both frameworks in parallel during the switch. The exact process varies between teams based on Selenium setup, and it requires technical know-how.

If you don’t have this expertise in-house, find a consultant who can advise you on your specific circumstances. A good one is worth the investment.

Still, it can be pretty useful to get an overview of what you need to do in a Selenium to Playwright migration, and when you need to do it. Here’s an at-a-glance guide for reference:

1. Audit your Selenium framework

Boring but necessary
Review test coverage and other key metrics – where could Playwright improve things?
Note key requirements for migration – what resources will you need, and when will you need them?
Discuss process retention – which workflows will you keep? Which will no longer work?

2. Choose your Playwright language

Playwright supports JavaScript/Typescript, Python, .NET, and Java
If you’ve chosen it for language continuity, carry on
However, you could use this opportunity to migrate from Java to TypeScript for better test maintainability – lots of teams do this

3. Install Playwright in your project

This one’s self explanatory

4. Convert basic tests

Start simple, then work your way through your test suite
What to be aware of: no WebDriver setup, built-in assertions, no explicit waits
If you’ve done it right, tests will become shorter and more readable

5. Replace wait strategies

Playwright automatically waits for element visibility, stability, enabled state, and network idle
This significantly reduces flakiness
Make sure you update migrated tests to benefit from this

6. Rebuild Page Objects

When you migrate Selenium to Playwright, your POM becomes cleaner, more asynchronous, and less dependent on driver injection
Ensure test scripts are set up to enable this

7. Simplify parallel execution

Bid farewell to Selenium Grid and complex Docker setups
Playwright offers native parallelization
To maximize the benefits, simplify your execution strategy and remove unnecessary infrastructure

8. Update CI/CD

Remove WebDriver setup, driver binaries, and Grid services
Ensure that your CI is updated to store the test artifacts Playwright generates (HTML reports, trace viewer, screenshots on failure)

9. Migrate gradually

Do not try to do everything at once
Create a priority list for rewriting and migration
High-priority, high-value tests go first

10. Train your team

Make time for proper training – this reduces the likelihood of bad habits forming, and ensures you maximize efficiency gains
Focus training on key Selenium/Playwright differences, including:
Asynch waits
Locators
Fixtures
Debugging with Trace Viewer

11. Start using Playwright’s advanced features

After migration and training, the efficiency gains really start
Take a look at:
Network interception
Multiple browser contexts
Built-in tracing
API testing

What Are The Challenges of Migrating from Selenium to Playwright?

The two challenges that stall most migrations are user buy-in and the temporary dual maintenance of both frameworks. Migrating from Selenium can also feel intimidating: for many teams, it is the only test automation tool they have ever used.

The key is anticipating these challenges and planning how to address them in advance. Consider the following:

1. User Buy-In

Migrating from Selenium to Playwright will only work if your users buy into the change, and embrace it. However, people are naturally change-resistant. This creates a dilemma.

(This doesn’t mean that your team are luddites – just that they’re following a natural ‘if it’s safe, why move’ evolutionary instinct). To alleviate:

Communicating the benefits early. Chances are, there’s plenty that your team doesn’t love about Selenium – show them how Playwright fixes that
Staggering training – a huge info-dump will make things seem insurmountable. Delivering training in bite-sized pieces is more manageable
Encouragement – there may be setbacks, and things may operate less efficiently as your team gets the hang of a new tool. Reward your team’s commitment and perseverance, show recognition for their efforts, whatever works in your organization

2. Temporary Dual Maintenance

You won’t be able to migrate all your tests at once – which means you’ll need to maintain both Selenium and Playwright as you complete the switch. If you don’t organize this properly, things could get pretty chaotic. Make sure to:

Be super clear about which tests are migrated, and when they will be migrated
Check in regularly with stakeholders to avoid misunderstandings
Run a tight ship, administratively speaking – update key documentation as you go, and maintain a single source of truth throughout the project

Which tools convert Selenium tests to Playwright?

No tool converts a Selenium suite to Playwright and gives you tests you can trust without a review. The options are a manual rewrite, a coding agent that ports one file at a time, or a move to a test format that an agent writes from the spec instead of from the old code.

Here is what each option does and where it stops:

Playwright codegen records a new test from a browser session. It does not read Selenium code, so it replaces a Selenium test instead of converting it. Use it when the old test is short and the flow is easy to click through.
A coding agent (Claude Code, Cursor, Codex, Devin) converts Selenium Java, Python or C# to Playwright TypeScript. It handles the mechanical part well: driver setup, locators, waits and assertions. It still needs a run and a review for every file, because the agent cannot see the app when it writes the code.
Community scripts on GitHub rewrite the driver API calls with regular expressions. They cover a small part of the WebDriver API, and they do not touch page objects, waits or test data. Treat their output as a starting point, not as a converted test.
Momentic ships no automatic converter from Selenium. Instead, a coding agent with the Momentic MCP server or the coding agent skills writes the YAML test from the existing spec, then runs it and reads the result.

The Momentic path is documented in Test portability. Keep the Selenium suite running, port the highest-value flows first, and delete an old spec only after its replacement passes a few consecutive runs.

What breaks when you move Selenium tests to Playwright?

Explicit waits, driver management, Selenium Grid and driver-injected page objects break first, because Playwright removes the layer they depend on. Locators, iframes and multi-window flows need a rewrite, not a search and replace.

Plan for these six breakages before you convert the first file:

WebDriverWait and implicit waits. Playwright waits for an element to be attached, visible, stable and enabled before it acts. A ported wait either does nothing or hides a real bug. Delete the wait and let the locator action or the web-first assertion (expect(locator).toBeVisible()) do the work.
Driver binaries and WebDriverManager. Playwright installs its own browsers with npx playwright install. Every driver download step in CI goes away.
Selenium Grid and remote WebDriver URLs. Playwright runs tests in parallel with workers on one machine, and across machines with --shard. The Grid hub, the nodes and the Docker files that ran them are no longer needed.
Page objects that receive a WebDriver in the constructor. Playwright page objects receive a Page, and every method becomes async. A Java suite with synchronous chains needs await on every line in TypeScript.
switchTo().frame() and switchTo().window(). Playwright uses page.frameLocator() for iframes and a new Page object for each tab or popup. Alerts move from switchTo().alert() to page.on('dialog').
Cloud grid configuration for BrowserStack or Sauce Labs. Both vendors run Playwright, but with a different connection method (a CDP endpoint, not a WebDriver capability), so the config file changes even when the vendor stays.

Locators do not break, but they cost you the most time. A Selenium suite full of absolute XPath keeps working in Playwright and stays as brittle as before. Convert to getByRole, getByLabel and getByTestId while you port, or the migration moves the maintenance problem without fixing it.

Can a coding agent convert a Selenium suite?

Yes. A coding agent converts Selenium code to Playwright faster than an engineer, and the same agent can write the flow as a Momentic YAML test instead. The difference is what the agent does after it writes the file.

For a Selenium to Playwright port, give the agent one test file, the page objects it imports, and a prompt like this:

Convert this Selenium Java test to Playwright TypeScript.
Use getByRole, getByLabel or getByTestId locators. Remove every
explicit wait and use web-first assertions. Keep the test name
and the assertions. Run `npx playwright test <file>` and fix
failures until it passes.

The agent produces a file that compiles. It does not know whether the locator matches the real page until the test runs, so the loop that matters is run, read the failure, correct the code. In practice an engineer still reviews every converted file, because the agent will invent a test ID or drop an assertion it could not map.

With Momentic the agent skips the Playwright code and writes the test as steps in plain English:

@Test
public void checkoutShowsConfirmation() {
    driver.get("https://shop.example.com");
    new WebDriverWait(driver, Duration.ofSeconds(10))
        .until(ExpectedConditions.elementToBeClickable(By.id("checkout")))
        .click();
    driver.findElement(By.name("email")).sendKeys("jeff@example.com");
    driver.findElement(By.cssSelector("button[type=submit]")).click();
    assertTrue(driver.findElement(By.className("confirmation")).isDisplayed());
}

fileType: momentic/test/v2
id: checkout-shows-confirmation
url: https://shop.example.com
steps:
  - click: Checkout
  - type:
      text: jeff@example.com
      into: Email input
  - click: Place order
  - assert: An order confirmation is visible

The YAML file lives in your repository next to the code. The agent writes it with the Momentic MCP server or the coding agent skills, runs it with npx momentic run, and reads the step that failed, the screenshot and the trace. When the checkout button is renamed later, Momentic re-resolves the element from the step description instead of failing on a selector.

How long does a Selenium to Playwright migration take for 500 tests?

Plan 3 to 6 months of one engineer for a manual rewrite of 500 tests, 6 to 10 weeks with a coding agent doing the conversion and an engineer reviewing, and 4 to 8 weeks for an agent-assisted move to Momentic. These are planning figures. Convert your first 20 tests, measure the hours per test, and rescale before you commit a date.

The figures come from a per-test estimate, and the per-test cost is what changes between the three paths:

Path	Hours per test	500 tests	What the engineer does
Manual rewrite in Playwright	1 to 3	500 to 1,500 hours	Reads the Selenium test, writes the Playwright test, rebuilds the page object, debugs the run
Coding agent writes Playwright, engineer reviews	0.5 to 1	250 to 500 hours	Reviews the diff, runs the test, corrects locators the agent guessed
Coding agent writes Momentic YAML, engineer reviews	0.3 to 0.6	150 to 300 hours	Reviews the steps against the spec, runs the test, accepts the result

Two costs are not in the table and apply to both Playwright paths: the page objects, which you rebuild once per page and not once per test, and the dual maintenance period, in which every UI change costs a fix in Selenium and a fix in Playwright. With Momentic the second cost falls away for the ported tests, because the test updates when the UI changes and the change is a diff in your repository.

Cost follows the same shape. At a loaded engineer cost of $100 per hour, the manual rewrite of 500 tests costs $50,000 to $150,000 in engineering time before the suite runs in CI. The agent-assisted paths cost $15,000 to $50,000 in review time plus the tooling. Put your own rate and your measured hours per test in the same formula.

How do Selenium Grid parallel runs map to Playwright workers in CI?

A Grid node becomes a Playwright worker, and a Grid with several machines becomes a sharded run. Set workers in playwright.config.ts for one machine, and pass --shard=1/4 on four CI jobs to split the suite across machines.

# .github/workflows/e2e.yml
jobs:
  e2e:
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/4

Three rules keep the mapping honest. Tests that shared state on the Grid, such as one login account, fail under workers because each worker runs in its own browser context. Playwright reports arrive per shard, so merge them with npx playwright merge-reports or upload each blob as an artifact. And the retry count in playwright.config.ts replaces the rerun-failed-tests plugin you had in Selenium.

Is a Selenium to Playwright migration worth it in 2026?

A Selenium to Playwright migration is worth it in 2026 when the suite is under about 300 tests, the team already writes TypeScript, and Selenium Grid costs more than an engineer-week per quarter to run. Above that size, or when maintenance hours are the real cost, the port only moves the problem, and a move to an agent-maintained format pays back sooner.

Use this table to make the call. Each row is one input that changes the answer; the last column gives the path that wins on that input alone.

Input	Migrate to Playwright	Stay on Selenium	Move to Momentic
Suite size	Under 300 tests: a port fits in one quarter	Over 1,000 tests and stable: the rewrite cost is not paid back	Any size: the agent writes tests from the spec, not from the old code
Java or TypeScript	TypeScript team: Playwright is the native fit	Java team with no plan to change: Selenium keeps the language	Either: the test is YAML, and the agent works in both repos
Grid cost	You run your own Grid: Playwright workers and --shard remove the hub and nodes	You already pay a cloud grid that runs Selenium well	Momentic runs the browsers, so the Grid line item goes away
Maintenance hours	Under 10 hours a week: auto-waiting cuts the flaky share	Under 5 hours a week: no reason to move	Over 10 hours a week: tests re-resolve elements when the UI changes, so the hours drop

Add up the rows. Two or more rows in the Playwright column make the port worth it. Two or more rows in the Momentic column mean the port is a detour: you pay for a rewrite and keep the maintenance bill.

Yes for speed, no for maintenance. Software testing is faster, simpler, and easier to scale with Playwright, but you still own a code-based suite. If you plan your migration properly, you are likely to start realizing those efficiency gains relatively soon after implementing.

On the other hand, Playwright is no longer the* creme de la creme *of software testing tools. You’re still anchored to writing tests in code, and auto-waits don’t solve your ongoing test maintenance burden. If you’re looking to shift left and up your release cadence (and in this environment, you need to), Playwright will only get you halfway there.

Momentic removes the two costs that Playwright keeps: writing the test in code, and fixing it when the UI changes. It does this with functionality that Playwright does not offer:

Natural language test creation: create tests in plain English – it takes seconds, and makes it much easier for your engineers to test as they go and avoid huge find-and-fix bottlenecks just before code is shipped
Version-controlled YAML: tests live in your own repository as plain English, so engineers and coding agents can read, diff, and maintain them like source code
Intent-based locators: these update your test when the UI changes – tests self-heal, minimizing your test maintenance burden and freeing up engineering hours for other, more valuable tasks
AI agents: Mo, your autonomous AI coworker, explores your app, evaluates critical user flows, generates new tests, and reports the bugs it finds. Routine maintenance runs in the background

If you migrate from Selenium to Playwright now, chances are you’ll need to migrate again in a couple of years when you realize that AI offers steeper efficiency gains.

Why waste effort migrating to a system that’s on its way out? Migrate straight from Selenium to an AI-native testing tool to really see the difference.

Migrate to Momentic

We went from 1-2 months for 80% user flow coverage to 1-2 days.

— Aditya Advani, Best Parents

Momentic is an AI testing solution that’s designed to be intelligent, intuitive, and fast. Implement on Day 1, test on Day 1.

Here’s how Best Parents reached 80% user flow coverage in just one day after implementing Momentic – with tests written in plain English.

Want to join them? Talk to our engineering team today.

FAQ

How do I migrate a Selenium suite to Playwright?

Audit your Selenium framework, choose a language, install Playwright, convert basic tests, replace wait strategies, rebuild page objects, simplify parallel execution, update CI/CD, migrate gradually, train your team, then adopt advanced features like tracing and network interception.

Is there a tool that converts Selenium tests to Playwright?

No tool reliably converts Selenium tests to Playwright, so teams rewrite them by hand or have a coding agent port them. Another path is Momentic, where tests are plain-English YAML that self-heal when the UI changes.

What breaks when you move Selenium tests to Playwright?

Explicit waits break because Playwright auto-waits for actionable elements. WebDriver setup and Selenium Grid are no longer needed. Page objects must be rebuilt for async locators, and CI must store Playwright's trace and screenshot artifacts.

How long does a Selenium to Playwright migration take for 500 tests?

Plan 3 to 6 months of one engineer for a manual rewrite of 500 tests, 6 to 10 weeks with a coding agent converting and an engineer reviewing, and 4 to 8 weeks for an agent-assisted move to Momentic. Convert 20 tests first and rescale from the measured hours per test.

Is a Selenium to Playwright migration worth it in 2026?

Yes when the suite is under about 300 tests, the team writes TypeScript, and you run your own Selenium Grid. No when maintenance hours are the main cost: the port keeps a code-based suite, so move to tests that an agent writes and maintains instead.

Can a coding agent convert our Selenium suite for us?

Yes. Claude Code, Cursor, Codex or Devin convert Selenium Java or Python to Playwright TypeScript one file at a time, and an engineer reviews and runs each file. The same agent can write the flow as a Momentic YAML test with the Momentic MCP server, then run it and read the failure.

Using Cursor for UI Testing: How Much Can AI Actually Automate?

Wei-Wei Wu — Sat, 31 Oct 2026 09:54:42 +0000

Originally published on the Momentic blog.

Yes, Cursor can write and edit UI tests. It drafts Playwright or Cypress tests from a user story, writes page objects and mocks, and fixes broken selectors when you ask. Its agent can also drive a browser to click through your running app, but it does not keep those checks as tests that run again in CI. Connect it to a test runner, such as the Momentic MCP server, to close that gap.

Can you use AI code generation tools like Cursor for UI testing? TL;DR yes, with some caveats. They accelerate test creation and maintenance without offering some of the steepest efficiency gains agentic AI tools offer.

Depending on your requirements, this is no bad thing. But it’s important to understand what Cursor does well and what its limitations are before building an entire testing strategy around it. It will suit teams looking for an AI solution that sits on top of their existing framework and takes some of the grunt work out of your existing processes. It won’t suit those looking to do away with slow, cumbersome frameworks entirely.

Here’s how Cursor accelerates testing, what it won’t help you with, and what your alternatives are.

Cursor for UI Testing: What It Does Well

Cursor does four UI testing jobs well: it drafts test cases from a user story, writes Playwright or Cypress code, edits broken selectors on request, and generates mocks and test data.

If you’re looking for an AI testing tool that will shave some time off established processes, Cursor offers plenty to like. This makes it ideal for teams in that ‘in-between’ stage, if you’re using it as a coding agent and aren’t quite ready to add another tool to your stack, using Cursor for UI testing can help accelerate release cycles.

Test Creation With AI

One of the major pain points of traditional test automation frameworks is the effort required to create tests in the first place. If, as many modern organizations do, your engineers test code themselves without external QA handoff, this significantly eats into time spent on ideation and feature development.

Using Cursor for UI testing allows you to significantly reduce time spent on authoring tests in two key ways:

Generating Test Cases From Requirements

Paste a user story and let Cursor generate the set of tests required to validate it. Cursor’s AI is relatively intelligent when it comes to what to test, as well as obvious happy-path tests, it can suggest edge cases, error scenarios, and accessibility checks to incorporate into your test suite.

Writing Playwright/Cypress code

This is where Cursor offers the strongest efficiency gains. Cursor can generate code for Playwright, Selenium, and other traditional frameworks that’s complex enough to include

page objects, selectors, test setup, assertions, and mock APIs.

It’s good enough to understand large, complex codebases (including React components, Next.js pages, and API routes) and to generate tests that actually match your implementation, rather than generic templates or examples.

It’s not perfect 100% of the time, but it gets you much closer than starting from scratch. Cursor code generation plus human review is far quicker than getting humans to code everything from scratch.

AI-Assisted Test Maintenance

Using traditional frameworks, maintaining UI tests is often more expensive than writing new ones, in terms of engineering hours. As a result, teams either dedicate huge amounts of time to test maintenance (to keep test suites compact) or simply write new tests whenever needed, causing unnecessary bloat. Neither option is ideal.

Using Cursor for UI testing significantly reduces the time needed to maintain your tests. With the right prompt, Cursor’s AI can:

Refactor selectors
Update page objects
Fix broken locators
Rename methods
Convert old patterns to new ones

When you’re shipping multiple minor UI updates per week, this is a particularly useful tool to have on hand.

Generating Mocks and Test Data

Cursor is very effective at creating mock API responses, fixtures, factories, seed data, and edge-case datasets. This saves a significant amount of repetitive manual work for your team.

Where Cursor for UI Testing Falls Short

Cursor falls short in four places: dynamic UI behavior, assertions about business outcomes, selector stability, and turning browser exploration into repeatable tests.

Cursor Often Misunderstands Dynamic UI Behavior

This is a major point for teams using Cursor for UI testing. Dynamic behavior is common in modern web and mobile apps, and Cursor often misreads state transitions, real-time updates and other dynamic behavior. That makes it an incomplete solution on its own.

Cursor Struggles to Find the Right Assertions

Cursor’s AI will typically test “does the button exist?” over “was the order successfully submitted?” Generally, it lacks the domain knowledge to test business-critical assertions. This risks leaving important issues untested while giving the impression of broader coverage. Superficially scaling test coverage is easy with Cursor, but ensuring that coverage is meaningful takes significantly more effort.

Cursor Generates Tests With Unstable Selectors

On the one hand, using Cursor for UI testing helps accelerate test maintenance. On the other hand, teams report that Cursor-generated tests add to that burden by generating brittle selectors that increase flakiness.

So, you maintain tests quicker, but generate more tests for which maintenance is required, and in-depth human review is still needed to ensure locator quality. Your net time spent on maintenance is still likely to decrease, but those efficiency gains are hampered significantly.

Cursor Can Explore Your App, but It Does Not Keep What It Finds

Cursor’s agent can now control a browser. Its docs describe navigating, clicking, typing, taking screenshots, and reading console logs and network traffic to test an app. That is useful for checking a change while you build it. But Cursor is still a coding agent, not an agentic testing solution. A browser session in chat is not a saved test that runs again in CI, and browser actions need your approval by default.

For example, Cursor can click through a checkout flow and report what it saw, but that check ends with the chat. To keep the coverage, you still turn it into framework code and maintain its selectors. What it explores, and which coverage gaps it finds, still depend on what you ask it to look at.

Cursor for UI Testing: An Example Workflow

A practical Cursor workflow splits the work: a person sets the test strategy and reviews the assertions, Cursor writes the skeletons and boilerplate, CI runs the tests, and Cursor helps fix the failures.

Can you use Cursor for UI testing effectively? Absolutely, if you understand what it can and cannot do, and build your workflows around that.

Assuming that Cursor can take care of absolutely everything will result in disappointment. Seeing Cursor as a tool that accelerates code creation, with humans still entirely responsible for code quality, is a much more effective way of structuring things. A template workflow might look a little something like this:

Human defines test strategy
AI generates test skeletons
Human reviews assertions
AI writes boilerplate
CI executes tests
AI helps fix failures

Cursor Alternatives: AI-Native Testing Solutions

The alternative to Cursor-written framework code is a testing tool that Cursor can drive. With Momentic, Cursor writes the test as plain-English steps, runs it, reads the failed step, screenshot and trace, and corrects its own code.

Rather than simply accelerating your existing processes, AI-native testing solutions add a whole new dimension to your strategy. Intelligent, agentic solutions move beyond code creation and maintenance on demand to a more intelligent approach.

An agentic tool runs the app while it tests. It can explore a stated area, report what failed with a screenshot and a trace, and point a person at the step that broke. You still decide what to test and review each change.

Momentic steps target an element by its description, not by a CSS selector. When a saved locator stops matching the page, Momentic finds the element again from that description. Cursor fixes a broken selector when you ask it to. Momentic re-resolves the element during the run, and you review the result in the run viewer.

This moves part of the maintenance work from your engineers to the test runner. With more AI-generated code to verify, that time adds up.

Does It Need to Be One or the Other?

Not necessarily. You can combine the flexibility of custom code with the exploratory capabilities of agentic AI by building critical paths in Playwright (with code generated and maintained by Cursor) while using AI testing solutions for broader regression and exploratory coverage.

This gives you the visibility of code where you need it, while significantly reducing the engineering hours needed to keep large UI suites running.

How do I connect Cursor to a test runner?

Install the Momentic MCP server and the Momentic skills in your project. The MCP server gives Cursor a live browser and tools to run, edit and triage tests. The skills tell Cursor which tools to call and in what order. See the MCP guide and the skills guide.

npx momentic install-mcp --client cursor --scope project
npx momentic skills --target cursor

The first command writes the server entry to .cursor/mcp.json. The second installs the skills in .cursor/skills/ and adds a pointer in .cursor/rules/momentic-skills.mdc. Restart Cursor, start a new chat, and ask which momentic_ tools are available.

Then the agent loop has four steps:

Cursor writes and runs a test with the Momentic CLI or the Momentic MCP server.
The run returns a structured failure: the step that failed, a screenshot and a trace.
Cursor reads that result and corrects its own code, then runs the test again.
Momentic maintains the test when the UI changes, and you review the change.

Can Cursor update my end-to-end tests when I change a component?

Yes, if the tests are files in your repository. Ask Cursor to run the affected tests after it changes the component, and to update a test only when the expected behavior changed. Review the test diff with the code diff in the same pull request.

A test that targets a CSS class breaks when Cursor renames that class. A Momentic step describes the element instead, for example "the Submit order button". When the saved locator stops matching, Momentic finds the element again from the description for that run, so a markup change does not fail the test.

This also stops Cursor from writing brittle selectors, because the test holds no selector. See locator auto-healing for how the re-resolution works.

AI Testing Tools vs Cursor for UI Testing: At-A-Glance Comparison

The table compares Cursor-written framework tests with an AI-native testing tool on purpose, authoring, maintenance and exploration.

Category	Cursor for UI Testing	AI-native testing tools (for example, Momentic)
Primary Purpose	AI-powered code generation and test maintenance on top of existing frameworks	Tests written as plain-English steps, run in a real browser, with failure evidence a coding agent can read
Best Fit	Teams that want to accelerate existing Playwright/Cypress workflows without changing their testing stack	Teams that want a coding agent to write, run and correct end-to-end tests in the repository
Test Creation	Generates test cases from requirements and user stories, including happy paths, edge cases, error scenarios, and accessibility checks	Plain-English steps in YAML files, written by an engineer or by Cursor through the Momentic MCP server
Test Maintenance	Assists with refactoring selectors, updating page objects, fixing locators, renaming methods, and modernizing patterns when prompted	Finds an element again from the step description when a saved locator stops matching; you review the result
App Exploration	The agent can click through the app in a browser, with each action approved by default, but sessions are not saved as repeatable tests	Mo explores a running app from an objective and files bugs with recordings and reproduction steps
Level of Autonomy	Human-driven; heavily dependent on prompts, review, and oversight.	The agent runs tests and reads the failed step, screenshot and trace; people review the diff
Testing Approach	Reactive and code-centric: humans define strategy, AI accelerates implementation	Tests live in your repository and run from the CLI in CI

Final Thoughts: Will Cursor For UI Testing Be Enough?

Cursor is enough when you keep Playwright or Cypress and review every generated test yourself. When you want Cursor to run the tests and act on the failures, give it a test runner it can call.

If you’re using it for code generation already, using Cursor for UI testing will give you some quick wins, coverage, and maintenance-wise. It won’t let you integrate AI with your testing processes to its full potential, however.

An agentic tool adds what Cursor does not have: a test runner that the agent can call, failure evidence it can read, and tests saved from exploring the running app.

To keep the flexibility of custom code, opt for Playwright and Cursor as a combination. To level up your testing processes and really accelerate your release cycles, choose a tool like Momentic, or a hybrid approach of the two.

We needed a way to own testing in-house without allocating too much engineering time toward addressing flakes. Momentic gave us that perfect blend of ownership, reliability, and flexibility.

— Aniruddha Laud, Head of Engineering, Pocus

How Pocus reduced flaky tests by a factor of 20 and now validates 100% of production deployments with Momentic

FAQ

Can Cursor be used for UI testing?

Yes. Cursor writes and edits Playwright, Cypress and Selenium tests from a prompt or a user story. Its agent can click through your app in a browser, but it does not keep those checks as tests, so an engineer or a connected test runner must run each test and check what it asserts.

Which test tools work with Cursor?

Any framework whose tests are code files, such as Playwright, Cypress and Selenium. Momentic also works with Cursor through its MCP server: run npx momentic install-mcp --client cursor, and Cursor can write, run and triage Momentic tests from chat.

How do I add a testing skill to Cursor?

Run npx momentic skills --target cursor in your repository. It installs the Momentic skills in .cursor/skills/ and adds a pointer in .cursor/rules/momentic-skills.mdc, so Cursor knows which test tools to call and in what order.

Can Cursor update my end-to-end tests when I change a component?

Yes, if the tests live in your repository. Ask Cursor to run the affected tests after the change and to edit a test only when the expected behavior changed. Review the test diff with the code diff.

How do I stop Cursor from writing brittle selectors?

Write tests that hold no selector. A Momentic step describes the element in plain English, and Momentic finds the element again from that description when the saved locator stops matching. In Playwright, ask Cursor for role-based or test-id locators.

Can Cursor fix a failing test on its own?

Only with the failure in front of it. Connected to the Momentic MCP server, Cursor runs the test, reads the failed step, screenshot and trace, and corrects its code. You review the diff before merge.

DEV Community: Wei-Wei Wu

Mobile MCP servers: set up Appium MCP, Maestro MCP and mobile-mcp

TL;DR

Appium MCP, Maestro MCP and mobile-mcp compared

Setting up mobile-mcp

Setting up Appium MCP

Setting up Maestro MCP

Where an MCP session stops and a repeatable test starts

Running the resulting test in CI

Related reading

Frequently asked questions

Can these servers use physical devices?

Can one MCP configuration drive both iOS and Android?

How is Momentic’s MCP server different?

Must I abandon an existing Appium or Maestro suite?

Migrating from Selenium to Playwright: A Step-by-Step Guide

Why Migrate from Selenium to Playwright?

Playwright Executes Tests Faster

Playwright Offers Built-In Auto-Waiting

Playwright Handles Modern Apps Better

Playwright Offers Native Parallel Support

Playwright Requires Fewer Third-Party Integrations

How to Migrate from Selenium to Playwright In 11 Steps

What Are The Challenges of Migrating from Selenium to Playwright?

1. User Buy-In

2. Temporary Dual Maintenance

Which tools convert Selenium tests to Playwright?

What breaks when you move Selenium tests to Playwright?

Can a coding agent convert a Selenium suite?

How long does a Selenium to Playwright migration take for 500 tests?

How do Selenium Grid parallel runs map to Playwright workers in CI?

Is a Selenium to Playwright migration worth it in 2026?

Migrate to Momentic

FAQ

How do I migrate a Selenium suite to Playwright?

Is there a tool that converts Selenium tests to Playwright?

What breaks when you move Selenium tests to Playwright?

How long does a Selenium to Playwright migration take for 500 tests?

Is a Selenium to Playwright migration worth it in 2026?

Can a coding agent convert our Selenium suite for us?

Using Cursor for UI Testing: How Much Can AI Actually Automate?

Cursor for UI Testing: What It Does Well

Test Creation With AI

Generating Test Cases From Requirements

Writing Playwright/Cypress code

AI-Assisted Test Maintenance

Generating Mocks and Test Data

Where Cursor for UI Testing Falls Short

Cursor Often Misunderstands Dynamic UI Behavior

Cursor Struggles to Find the Right Assertions

Cursor Generates Tests With Unstable Selectors

Cursor Can Explore Your App, but It Does Not Keep What It Finds

Cursor for UI Testing: An Example Workflow

Cursor Alternatives: AI-Native Testing Solutions

Does It Need to Be One or the Other?

How do I connect Cursor to a test runner?

Can Cursor update my end-to-end tests when I change a component?

AI Testing Tools vs Cursor for UI Testing: At-A-Glance Comparison

Final Thoughts: Will Cursor For UI Testing Be Enough?

FAQ

Can Cursor be used for UI testing?

Which test tools work with Cursor?

How do I add a testing skill to Cursor?

Can Cursor update my end-to-end tests when I change a component?

How do I stop Cursor from writing brittle selectors?

Can Cursor fix a failing test on its own?