How-to

Environments and test fixtures

Register where tests run and what they need to log in (as pointers, never secrets), and watch manual cases turn automatable.

Applies toPlans:FreeProBusinessEnterpriseRoles:OwnerAdminDeveloperQaWhere:Web appMCP

The single biggest reason test generation produces MANUAL cases is not that the flow is unautomatable but that the agent had no way to get a login, an OTP, or a seeded account. Registering that information once turns a category of "cannot automate" into "automate like anything else".

Register an environment

Open Environments for the project.
Add a name (staging, preview, production) and the base URL tests should target.
Record the feature flags that are on there. A case that only exists behind a flag is worth knowing about before somebody debugs a "missing" button for an hour.
Set allows destructive honestly. Agents read it to decide whether a case that deletes data may run.
Mark one environment as the default. Setting a new default clears the previous one in the same transaction.

Register a fixture

A fixture has a kind, a name, a reference, and notes. The reference is the whole security model: it names where the secret lives on your side, and you resolve it in your runner or your agent. BugMojo never holds the value.

Kind	Typical use	Clears the reason code
`test_account`	A seeded login for a role	`DATA_SETUP_INFEASIBLE`
`otp_bypass`	A fixed code or bypass header in non-production	`OTP_2FA`
`psp_sandbox`	Payment-provider test keys	`REAL_PAYMENT`
`seed_data`	A script or dataset that puts the app in a known state	`DATA_SETUP_INFEASIBLE`
`feature_flag`	A flag a case depends on	None
`api_key_ref`	A third-party key held in your vault	`THIRD_PARTY_NO_SANDBOX`
`other`	Anything your team registers of its own	None

Valid references

E2E_ADMIN_PASSWORD                 an environment-variable NAME
STRIPE_TEST_SECRET_KEY             an environment-variable NAME
vault://kv/qa/staging/otp-bypass   a vault URI
op://Engineering/qa-login/password a secret-manager URI

What changes once they exist

Three things, immediately:

Classification moves. The rubric reads the fixture registry, so a registered bypass cancels the blocker it solves and the affected cases score as more automatable. Re-classify the plan after registering a fixture and watch the MANUAL count drop.
Generation stops guessing. An agent asks for the fixture by name instead of inventing a login flow it cannot complete.
Runs name where they ran. A result carries the environment, so "passed on staging" and "passed on production" are different facts in the report.

Reading them from an agent

text

list_environments   base URL, feature flags, which allows destructive tests,
                    which is default, plus the fixture registry
get_test_fixture    one fixture: kind, reference and notes

Common questions

Does BugMojo store my test passwords?

No. A fixture stores a <em>pointer</em> (an environment-variable name or a vault URI), and writes are refused if the value or the notes look like a live credential.

Why does registering a fixture change a case's mode?

The classification rubric reads the fixture registry. A fixture that solves a blocker cancels the reason code it covers, so the case scores as more automatable.

Can two environments both be the default?

No. The default is a singleton per project; setting one clears the others inside the same transaction, so concurrent writes converge on one winner.

What does allows_destructive actually do?

It tells generators and agents which environment may run tests that delete or mutate real data. It is a declaration you make, not an enforcement BugMojo can apply to your app.

Was this helpful?

Updated Sep 19, 2026 · Still stuck? Contact support