Discover and debug

Discover an app from its URL

On the dashboard's Overview, enter your app's URL (it defaults to the selected environment) and choose Explore this URL. Bugmole Cloud, or your own worker if you chose My resources, opens the app in a real browser and moves through it the way a first-time visitor does:

• It starts on the home page and follows the links a person can see, clicking them rather than jumping straight to URLs. It opens menus to find the links inside.
• It notes every page it reaches, every form, and the buttons on each page.
• It fills and submits each form and presses each button, then notes what followed: the page it opened, a message it showed, or a server error. Everything it types carries the exploration's fingerprint (bugmole-bm-k3x9q2, bugmole+bm-k3x9q2@example.com), and every request it sends to your app carries an x-bugmole-exploration: bm-k3x9q2 header. Search for the fingerprint to find or remove what it created. Overview lists the forms and buttons it used and the fingerprint.
• It never deletes, signs out, pays, changes a plan or sends anything to people (invitations, emails, messages, feedback), and it doesn't submit sign-in or sign-up forms (any form with a password field), which would change who it is signed in as. Each of those it meets is a card under Blockers, saying where it is, why it was left alone and how to test it. A confirmation dialog ("Are you sure?") is always answered no.
• On an environment set to Exploration only looks (in the environment's settings), it only looks: no forms submitted, no buttons pressed. Use it for production.
• It stays on your site and skips links that sign out or delete things.
• It stops at your plan's exploration limit: on Free, 12 pages, two clicks deep from home. See Plans and limits. When a limit stops it, the exploration log and What isn't covered yet say how many linked pages it didn't open, and which.

You watch the exploration live, with a rough estimate of when it will be done, and every page and form becomes a runnable flow:

Flows are saved under spec/flows/discovered/ and published as tests. Password fields are filled with {{secret.APP_PASSWORD}}; set BUGMOLE_FLOW_SECRET_APP_PASSWORD on the worker before you run those flows. Open Tests to run them on any browsers and devices; select a test and choose Show the test file to read or download exactly what it does.

Apps that start with a sign-in page

Discovery doesn't sign in on its own. When everything it can reach is a sign-in screen, it says Stopped at a sign-in page and doesn't guess at the app behind it.

To explore signed in on Bugmole Cloud, open Settings → Sign-in for runs (/manage/cloud-sign-in), save a sign-in flow and the secrets it types, and explore again: the exploration runs the flow first and explores as the signed-in user. See Sign-in for runs for where those secrets live and who can read them. From your machine or CI, pass the flow to discovery instead; see Getting started.

Multi-page journeys written by AI

Tick Also have AI write multi-page journeys to have AI turn the map into journeys a person would take, such as signing up and then buying something. It costs 100 AI credits, or nothing with your own model key.

AI only sees what discovery saw, and every journey it writes is checked against it: a journey that taps a button, opens a page or expects text that discovery never found is set aside, and the exploration log says why. When exploration stopped at a sign-in page, the AI step is skipped and costs nothing.

Flows in the journey graph

Discovered flows start as drafts. The Journey graph on Overview draws a flow as soon as a run of it passes, so what you see there has been proven in a real browser. Until then the graph says how many flows are waiting.

Cleaning up after exploration

Each exploration keeps a cleanup list: every request it sent that changes something (anything but GET, HEAD or OPTIONS), with the page and form or button that sent it, the status, and what it created when the reply says so (a Location header such as /items/7, or an id in a JSON reply such as project.id 7).

• On Overview, the exploration panel says how many changes it sent and what they created. Download the cleanup list saves them as JSON with the fingerprint, to work through by hand or with a script against your app's API.
• From the CLI, the list is writes in the output folder's discovery.json.
• To find everything, including changes your app made as a side effect, search your data for the fingerprint (bm-k3x9q2): it is in every value exploration typed. Your server logs can filter on the x-bugmole-exploration request header.
• The panel keeps the first 200 changes of a long exploration and says how many there were; the fingerprint finds the rest.

Bugmole doesn't delete what it created: deleting is one of the things exploration never does. Set Exploration only looks here on an environment where nothing should be created at all.

Keep track of runs

Runs lists every run the project keeps: its result, how long it took, and what started it (the dashboard, a pull request with a link to its GitHub check, or a commit). By test shows each test's last ten results and marks a test Flaky when it both passed and failed recently.

A run in progress shows roughly how long it has left and when to come back, based on how long earlier runs of the same test took. Explorations and agent tasks do the same.

Debug a failed run

Select a browser's result in a run to open it:

When a step fails, Bugmole records what was on the page — its controls and headings, error messages, and fields that are empty or invalid — and works out the cause:

• Test needs an update: a button or label was renamed, or the flow left a required field empty. Bugmole suggests the exact change to the flow.
• App bug: the page crashed, or what the flow expects is gone with nothing similar on the page.
• Environment problem: the app could not be reached.

AI then explains the failure in plain words. If your project configures its own AI model (see Configuration), that model does it at no credit cost; otherwise Bugmole AI does, for 1 AI credit per failure (see Plans and limits). The suggested change itself always comes from what Bugmole verified on the page.

Apply a fix

Apply fix starts a new run on the same browser with the suggested change written to the flow first. The flow file is updated where the plan keeps it, so the fix sticks. If the flow changed since the suggestion was made, the run stops and asks you to re-run for a new suggestion instead of editing the wrong step.