Test Data, Secrets and Environments

Keep usernames, passwords, PINs and one-time codes per app, use them in steps as placeholders, and keep secrets masked and away from the AI model.

Keep the values your tests type — usernames, passwords, PINs, one-time codes — in one place per app instead of in every step. Any test of the app can use them, whether or not it is in a group.

Test data

Each app has a list of named values. In a step, write the name in double braces:

Type {{username}} into the email field
Type {{password}} into the password field

On every run VibeView fills in the value before the step runs, and your saved test is not changed. A {{name}} with no matching value is left as written. Names are letters, digits and underscores, up to 128 characters; a value is up to 2000 characters, and an app holds up to 200 values.

When you review a new test, a step’s key button (or typing «) inserts a key; it is shown as a «key» chip and saved as {{key}}.

Test data belongs to the app: every group and test of the app shares it, so editing it from one place changes it for all of them. To run with different values (for example a staging account), use an environment: it overrides the app’s values for the runs that use it. The values are managed through the Tests API.

Secrets

Mark a value secret when it is a password, PIN, token or similar. A secret:

is write-only: it is never shown again, never returned by the API and never included in a YAML export (it appears as [MASKED]);
is masked wherever a run is shown — results, step reasoning, progress and logs — and a whole-value match is masked even when the secret is short, such as a 4-digit PIN (a longer number that merely contains those digits is left alone);
is never put in the AI’s prompts, step text, results or logs, and is hidden wherever it appears as text. The AI sees {{name}}, and VibeView types the real value into the device for it. The AI also sees screenshots, so a secret that is shown on screen reaches it. A recording replays {{name}} the same way. A recording that typed the value itself, rather than {{name}}, types it as recorded, and it is masked in the results.

Things to know:

A secret’s value is hidden wherever it appears, so a short or common value (such as “Google”) hides that word everywhere in the AI’s view and the logs. Don’t make such a value a secret.
Screenshots and video are not edited. If a secret is typed into a field that does not hide its text, the run’s screenshots and video can show it. Prefer password fields, or use a one-time code.
Because the value is never put in the AI’s text, a Verify step cannot check a secret. A step such as “Verify the label shows {{pin}}” cannot pass: it fails with a message saying that Verify steps can’t check secrets. Check that the right screen appears instead. A value that is not secret is filled into the step, so a Verify step can check it.
Only typing uses the value. Steps that open a URL or look for text on screen see {{name}} as written.
A secret is one line of text with at least one letter or digit.
A new value that arrives by import — a YAML import, a group’s variables in the API, or a Maestro import — is stored as a secret when its name looks like one: the whole name, or a part of it split at underscores or at camelCase capitals, is password, pass, passwd, pwd, pin, secret, token, otp, key, apikey, credential or credentials (any case). So LOGIN_PASSWORD, API_KEY, STRIPE_SECRET_KEY, apiKey and userToken are secrets, while KEYBOARD_LAYOUT and MONKEY are not. A blank value stays plain. A value you add yourself is secret only when you tick Secret.

One-time codes (TOTP)

A value of kind one-time code holds the base32 setup key your authenticator app shows when you enable two-factor sign-in. It is always secret. When a step types it, VibeView types the current six-digit code, so a test can sign in to an account that asks for a code.

Environments

An environment is a named set of overrides for one app — for example Staging next to the app’s own values, which act as the default. A run with an environment uses the app’s values with the environment’s values on top, and records which environment it used. An environment can also carry a default build selector.

Pick an environment in the Run dialog (Environment), or manage environments under App notes & data on the Tests page. The API takes it too (see Tests API); the CLI has no environment option yet. CI runs accept an optional environment (name or ID) in the request body; an unknown environment is refused with 404.

Linked apps

When the same app is linked across platforms (see Same app on other platforms), its test data is shared by every linked app:

On the Tests page, a linked product’s App notes & data shows one list: each key’s shared value and, next to it, an override for each platform of the form factor you are viewing. Leave an override empty to use the shared value; saving the shared value there removes the override. A secret’s override is write-only, like the shared value. Deleting a key there deletes it on every platform. See The Tests page.
Through the Tests API for one linked app, adding a value adds it for every linked app, changing one changes it for that platform only, and removing one removes that platform’s own value; a value shared by every platform is removed from the Tests page or the product’s own endpoints instead.
Creating, renaming or deleting an environment does it for every linked app.
A run uses the values of the platform of the device it runs on: the values every linked app shares, with that platform’s own values on top. A test made on iOS and run on an Android device types the Android values. On a device whose platform has no linked app, the run uses the shared values only.
In a run with an environment, the environment’s values come on top of those, so an environment value shared by every platform wins over a platform’s own value outside the environment. A platform’s own value inside the environment wins over both.
The AI gets the notes written for every platform, then the notes of the device’s platform.
A value that is secret on one platform is secret on every platform, and a run hides every secret of the linked apps from the AI and in its logs and results, including the other platforms’ secrets.

Start state

Each test starts from a known app state: Fresh install, Clean app data, Restart the app or Where the last test stopped (see Running tests):

A test can set its own start state, through the API (start_state, see Tests API) or the startState field of a YAML import (see YAML format).
Otherwise a test run as part of a group uses the group’s Start each test from setting, and the Run dialog can override it for one run.
A single test run outside any group starts from Clean app data. This applies to runs from the dashboard (including Run a test on the Devices page) and to runs started with the AI run API. On Roku, clearing data deletes the channel and installs it again.
A single test run from CI, including vibeview run-test, starts on a freshly installed app and is not reset.

Groups

A test can be in several groups, each with its own order. Deleting a group never deletes its tests: they stay, and appear under Not in a group if they are in no other group. Only the group’s run history is deleted.