How Bugmole finds what to test

This page covers where Bugmole's tests and test cases come from, what counts as covered, and where gaps can remain. The dashboard has the same explanation under Help → How Bugmole finds tests. Overview lists your project's own gaps under What isn't covered yet.

What Bugmole tests

Bugmole tests web apps and mobile apps (Android and iOS): what a person can open, tap and click. Data and AI projects, such as notebooks, pipelines and models, are out of scope. One project is one app, identified by its domain or by its git repository and the app's folder in it.

How Bugmole finds scenarios

• Site discovery. A real browser opens your app's address and moves through it like a first-time visitor. It follows the links a person can see and opens menus to find the links inside them. It notes every page, form and button it reaches. It also fills and submits forms and presses buttons, to reach what only an action shows (an item a form creates, a validation message, a server error). Everything it types and sends is marked with that exploration's fingerprint (like bugmole-bm-k3x9q2, and an x-bugmole-exploration header on its requests), so you can find and remove what it created. It never deletes, signs out, pays or sends anything to people, and doesn't submit sign-in or sign-up forms: each of those it meets is listed under Blockers with how to test it. On an environment set to Exploration only looks (production, say) it only looks. It stays on your site and skips links that sign out or delete things. How far it goes depends on your plan (see Plans and limits). When a limit stops it, it says how many linked pages it didn't open. See Discover and debug.
• Sign-in pages. Discovery doesn't sign in by itself. When all it can reach is a sign-in page, it says Stopped at a sign-in page and doesn't guess at the app behind it. Save a sign-in flow under Settings → Sign-in for runs and it explores as a signed-in user.
• AI exploration (optional). AI turns the pages discovery saw into multi-page journeys a person would take, such as signing up and then buying something. A journey that uses a page or button discovery never saw is set aside, and the exploration log says why.
• From your code. The bugmole CLI and AI agents working through Bugmole MCP read your repository's routes and links and build a journey graph from them. They then check each step in a running app, so a route in the source isn't treated as a working journey until a run has checked it.

How tests and test cases are written

• Every page and form discovery finds becomes a test. A page's test opens the app, clicks through to the page and checks its heading shows. A form's test fills each field with safe sample data and checks the submit button is ready. Select a test on Tests and choose Show the test file to read exactly what it does.
• Test cases are written for a journey, usually by an AI agent (bugmole_write_test_cases). Each one names the step it checks, the steps it takes and what should happen.
• Each test case also says what kind of scenario it is: happy path, invalid input, error or empty state, permissions, or edge case. Every step needs a happy-path case, and each other kind needs a case on some step of the journey. When a kind doesn't apply (a step with no input has nothing to validate, an app with one role has no permission scenarios), the case set says so with a reason instead of leaving a silent hole. Tests shows each journey as a table of steps and kinds of scenario, and a kind nobody wrote is listed under What isn't covered yet.
• Until a run checks it, a test case is an assumption: what Bugmole expects, based on what it read or saw, with a confidence (high, medium or low). It isn't something Bugmole observed. The Tests page labels these Assumption. A case a run has judged says Checked by a run.
• A case is only verified once a run records a result for it: passed, failed, blocked or needs setup. Changing a case creates a new revision, which counts as untested until a run checks it.
• A test run walks a journey the normal way, so it can pass only the happy-path cases on the steps it passed. Invalid-input, error-state, permissions and edge cases on those steps are recorded as blocked, saying the run didn't try them, until a check that does try them records a result.
• On real devices and device clouds, the checks that the page fits the screen and its links work can't run. Those steps show not checked instead of passed. They count as checked when the same run also covers a desktop or emulated browser.
• Anyone can propose adding, changing or retiring a test case. Your project's approval mode decides who accepts the change.

How audits are made

• An app audit checks every button and link on a screen: whether it does something, and whether it reaches your backend. Each finding keeps the screenshot or code it came from.
• A visual audit compares a screen with its design reference (a Figma frame, an image, a PDF or a URL) and records each difference in colour, size, spacing or text.
• Anything an audit couldn't check, such as a screen behind a login it has no account for, is listed as blocked rather than passed.

What "covered" means

• Covered means a run checked it and it passed. A test that was written but never run isn't covered, and neither is one whose latest run failed or was blocked.
• Coverage on Overview counts passing test cases when your project has them. Otherwise it counts tests whose latest run passed.
• Coverage only counts what Bugmole found. A page it never reached isn't in the total at all. So 100% means everything Bugmole found passes, not that your whole app is tested.
• Routes in your code gives a total that doesn't depend on what Bugmole found. Once the CLI or an agent has explored your repository, Overview shows how many of its screen routes a passing check verifies (for example 22/48 verified) and how many have been opened at all. Server handlers such as /api/… aren't counted. Routes nothing has opened are listed under What isn't covered yet.

Where gaps can remain

What isn't covered yet on Overview lists each gap it can see, why it's a gap, and what to do next:

A gap is only listed when something Bugmole recorded shows it. Parts of your app that no exploration or source reading has reached can't be listed, so explore again after your app changes.

How long will it take?

Before you start a run, Tests says how long it usually takes. The estimate is the typical time of that test's last ten finished runs. A test that has never finished a run is estimated from its number of steps, or from other tests in the project. The very first run says there's no estimate yet. Explorations are estimated in the same way from earlier explorations. The first one usually takes about 3 minutes, or 4 with AI journeys.