Map your app. Test the paths that matter.

Give Cartographer an authorized app and a goal such as “sign up, enter the email code, and open the workspace.” It follows the route, returns the pages and browser actions it reached, and gives you a check to review or rerun.

Exploration and test export are in beta. Exported tests are plain Playwright that run without Molar.

See how someone gets from signup to a working account.

Start with an authorized URL and a concrete goal. Cartographer’s agent follows the pages that matter, then leaves the route, browser action, and expected result together.

Illustrative map · no request is sent from this demo.

route map / example runnorthstar.test6 routes · 2 branches
observed route branch to inspect

Select a route to inspect the state Cartographer would carry forward. The Blocked branch makes permissions visible instead of quietly treating an inaccessible page as a success.

Read the action.
Then check the result.

A click can work while the checkout is still wrong. Inspect the selected element, the browser action, and the result that made the check fail.

Interactive example · checkout totalFailed at the receipt check
Goal

Buy Pro for $24 and confirm the account has Pro access.

Check the receipt total

Failed
Selected element
page.getByTestId('receipt-total')
Browser action
Compare the visible receipt total with the expected price.
Receipt
Total shown$240.00

The amount check failed. Later account-access checks have not run.

Expected
$24.00
Observed
The receipt shows $240.00, not the selected $24.00.

Sample data · select a step to inspect it. The failed amount check remains failed when you review earlier actions.

Give the exploration a useful boundary.

Choose a starting page, the account role, and the part of the app you want to understand. The map reflects what the run observed within those limits.

  1. Start with the right environment

    Use a preview or test app for flows that create accounts, submit forms, or change data. Connect its test services before exploring payment or messaging paths.

  2. Choose the account’s point of view

    A saved member profile and an admin profile reveal different routes. Profiles must belong to the same project and website as the exploration.

  3. Set the area and size of the map

    Limit allowed hosts, link depth, total pages, and repeated URL patterns. State a focus such as signup and settings so the run has a useful starting point.

  4. Read the limits with the results

    Check which pages and transitions were observed, where access was missing, and whether a limit stopped discovery. An unexplored route is not a passing check.

Project crawl API · example request body
{
  "base_url": "https://preview.example.test",
  "depth": 3,
  "max_pages": 40,
  "max_per_pattern": 4,
  "scope_allowlist": [
    "preview.example.test"
  ],
  "crawl_focus_prompt": "Explore signup and account settings",
  "auth_context": {
    "mode": "browser_profile",
    "browser_profile": "qa-member"
  }
}

Send this body to POST https://api.molar.it/v1/projects/{project_id}/crawls with your API token. Replace the URL and use an existing qa-member profile for that project and origin.

Read the API setup docs
Pages and transitionsWhat the browser reached
Controls and actionsWhat it could inspect or use
Results and limitsWhat passed, failed, or remains unknown

A generated file still has to pass.

Keep the browser observation, the assertion, and the replay result separate. That is how you judge whether a generated test belongs in your suite.

01

Capture the flow

Use the recorded actions and observed page states to identify what the test should do.

02

Inspect the code

Review the selected elements, setup, and assertions. A click is not proof of the expected result.

03

Replay from a clean start

Run the generated test with fresh fixtures. Check the actual assertion results and retained artifacts.

04

Add it to your suite

Review the verified test in your repository and configure when it should run.

Make the assertion name the bug.

“The receipt appeared” would miss this example’s price error. Check the receipt total against the amount the customer selected.

Illustrative Playwright assertion
await expect(page.getByTestId('receipt-total'))
  .toHaveText('$24.00');

Already using Playwright codegen?

Codegen records your browser interactions and can generate visibility, text, and value assertions. Cartographer adds goal-driven exploration and a map of the routes it observes. Keep existing tests and review new generated tests alongside them.

How Playwright codegen works

Start from your terminal.
Bring the result to your team.

Explore routes, run a specific task, or verify a page state. Choose the command that matches the job.

Explore signup and settings

With --mode preview, exploration covers only the flows you name and finishes sooner. It returns a route map, not a test file.

Molar CLI · explore
molar explore https://preview.example.test \
  --intent "cover signup and settings" \
  --max-pages 40 --mode preview --json

Complete a browser task

Use a configured test account and a local app for a workflow that may change state.

Molar CLI · run
molar run "sign in and reach the dashboard" \
  --url http://localhost:3000 --json

Check what is on a page

Check a claim against the URL without asking for a state-changing workflow.

Molar CLI · verify
molar verify "the login form is visible" --url http://localhost:3000 --json

Look beyond the broken click.

Turn on the additional checks you want on visited pages. Review the reported issue and its page context.

Accessibility findings

Automated rules can flag issues such as missing form labels. They support accessibility work; they do not replace a complete audit.

Visual changes

Compare captured pages with a configured baseline to inspect layout or appearance changes.

Additional visual review

Optional sampled checks can flag potential UI problems for review. Sampling and its budget limit what gets examined.

Watch Molar complete a real browser task.

This recording is an actual controlled public browser check: four observed actions, a final screenshot, and a result record. Watch it add an element, confirm it appeared, remove it, and check its absence. This recording is separate from the illustrated route map above.

Open the recorded run details
Controlled public checkActual capture · final state
  1. 01Add the element
  2. 02Check it appeared
  3. 03Remove the element
  4. 04Check it is gone

Frequently asked questions

Have a specific workflow in mind?
Talk to us

What should I give Cartographer first?

Give it an authorized URL and one concrete goal, such as reaching a dashboard after email verification or showing an order receipt after checkout.

Can Cartographer run against localhost?

Yes. Runs against localhost use a browser on your own machine. Hosted runs use the target and saved logins you configure.

What does the route map represent?

It represents pages and transitions observed during an exploration or task. Select a route to inspect its browser actions, expected result, and illustrative assertion.

Can I use a signed-in test account?

Yes. Save a test account as a saved login or browser profile for the project. Molar uses it only on the project’s own hosts.

What is the difference between molar run and molar verify?

molar run starts a goal-directed browser task and may change state. molar verify checks a claim against a URL or prior task result and is intended for read-only verification.

Can I keep my Playwright suite?

Yes. Keep your Playwright tests. Exported Cartographer tests are plain Playwright files you can add alongside them.

Does reaching a page mean the flow passed?

No. A discovered page or a completed click is not an assertion. Check that the requested result was observed, and review blocked or unvisited branches separately.

Can I record a flow with the browser extension?

Not yet. Recording with the browser extension is in development.

What happens when access or setup blocks a run?

The run can return a blocked status with the available task, Trace, screenshot, and artifact references. Review the missing access or input before trying again.

Start with one task in your app.

Create a free workspace, add your app’s URL and a test account, and describe the first task to check.

Free during the beta. No card.