| name | minitest-capabilities |
| description | Canonical Minitest product capabilities and scenario-authoring rules. Use when creating, reviewing, or changing apps, scenarios, acceptance criteria, personas, dependencies, device counts, connectivity coverage, or app knowledge. |
Minitest Capabilities
Use these rules whenever reasoning about a Minitest suite. In the product UI,
a user story is called a scenario and a batch is called a run.
What Mini can test
This envelope is the rendered mini-capabilities fragment from Minitap's
capability source of truth. Do not edit it by hand — refresh it with
minitest capabilities (add --platform <ios|android|web> to see only what a
given platform supports).
Mini is the Minitap testing agent. It drives real Android, iOS and web sessions and executes acceptance criteria. A criterion Mini cannot physically perform or observe will fail as unprocessable, not because the app is broken.
What Mini can do:
- Gestures: tap (by label, coordinates or screen percentage), long-press, swipe, drag (including pick-up drag with a hold before the move), pinch and zoom. (Android, iOS, web)
- Curved gestures: an arbitrary path in a single press-move-release — circles, arcs, loops, figure-eights. Rotary dials, knobs, circular unlocks, pattern locks, signature pads and arc sliders are all testable. (Android, iOS, web) Android: Paths anchor to an element's bounds. iOS: Paths anchor to an element's bounds.
- Text: type into the focused field or a targeted element, erase, press enter. (Android, iOS, web) Android: Can also navigate back and home.
- Observation: screenshots (standard and high-res), a compact or full UI hierarchy, finding elements by text or label, and visual questions. (Android, iOS, web)
- App lifecycle: launch, stop, open a URL or deep link, install a provided build. (Android, iOS)
- Media & audio: speak text aloud or play an audio file into the browser microphone, and transcribe what the browser's speakers output. (web)
- Camera: the browser camera is simulated — a per-story image or MP4 is fed as the live webcam feed, so QR scanning and document presentation are testable. (web)
- Files: push a file to the device for upload and attachment flows, seeded from story-bound test files. (Android, iOS, web)
- Connectivity: change the network state mid-run. (Android, web) Android: Wifi on/off, airplane mode, and reading the connectivity state. web: Take the page offline and back online.
- Screen orientation: rotate to landscape or portrait. (Android, iOS)
- Device state: grant or revoke permissions without the system prompt, and switch between light and dark appearance. (Android, iOS, web) iOS: Can also freeze the status bar to a fixed time and battery for stable screenshots.
- Push notifications: deliver an arbitrary payload to the app under test. (iOS)
- Geolocation (cloud devices): mock GPS, simulate movement along a route at a given speed, and restore the real location. (Android, iOS) Android: Play Services
GeofencingClient transition callbacks may not fire (cloud devices run microG, not real GMS); apps reading location directly work fine.
- Identity & email: read any
<prefix>@qa.minitap.ai inbox for OTP codes, verification links and magic links, and sign in with Google through the shared Minitap account pool (leased at runtime, 2FA handled). (Android, iOS, web)
- Replay: re-run a previously captured trajectory to reach a known state faster. (Android, iOS)
- Multi-device: up to
min(3, tenant device quota) devices at once, set by the scenario's device-count setting. Auto resolves to one device per bound persona (minimum one), so a sequential multi-persona scenario pins an explicit count of 1. The count is decoupled from personas — two devices on one persona for session-conflict tests, or one device and two personas by signing in and out. This is what makes real-time cross-account behaviour assertable. Every device runs the same OS and the same app. (Android, iOS)
What Mini cannot do — never write criteria that require:
- Server-side, database, log or analytics verification — only what is visible on screen counts. (Android, iOS, web)
- Receive SMS or phone calls, or read email outside
@qa.minitap.ai inboxes. (Android, iOS, web)
- Biometric auth (fingerprint, Face ID), hardware buttons beyond back and home, NFC, or Bluetooth pairing. (Android, iOS)
- Use camera input. (Android, iOS)
- Feed audio into the microphone or hear what the app plays — the cloud device provider exposes no audio path, so voice-driven flows are web-only. (Android, iOS)
- Toggle connectivity or airplane mode. (iOS)
- Rotate the viewport or mock a location — the stealth browser pins the window to its fingerprint and blocks the geolocation override, so pick the right viewport preset up front. (web)
- Pair with a smartwatch, wearable or other external hardware (a second phone or tablet IS supported). (Android, iOS, web)
- Enter a real payment card or make a real-money purchase (sandbox flows only). (Android, iOS, web)
- Guarantee precise timing or gesture velocity ("responds within 200ms", "flick fast enough to fling the list") — Mini observes order and outcomes, not millisecond latency, and gesture pacing is approximate. (Android, iOS, web) Android: Pacing is noticeably slower than requested.
Every criterion must stay within these observable capabilities.
Scenario design
A scenario is one fresh, self-contained test session. It owns the path from app
launch to the state it tests, including sign-in, onboarding, navigation, and
cheap reversible setup. Put that setup path in the description and keep the
acceptance criteria focused on what to verify once there.
Default to one scenario per feature area. Once Mini has paid the cost to reach a
feature, cover the reachable behavior thoroughly in that session. Split only
when at least one of these is true:
- The app needs a reset or irreversible state change between journeys.
- A different persona runs a genuinely separate journey.
- The journey requires an entry path unavailable through in-app navigation.
- Isolation gives a meaningfully clearer failure signal for an independent
capability.
Keep collaborative journeys that span accounts in one scenario when the
identities act within one flow. Bind all needed personas, then choose devices
based on whether those identities must be simultaneous.
Cover every major user-facing flow, including happy paths, validation and
failure states, permission or authentication denials, empty states, and
meaningful edge cases. Prefer fewer complete scenarios over many vague ones.
Model the product variant most users see when a feature flag creates multiple
visible variants, and record important rollout caveats in the scenario
description or app knowledge.
Titles, descriptions, and acceptance criteria
Every scenario requires all three fields:
- Title: begin with a verb and describe a user-facing action.
- Description: use one or two sentences for intent, scope, and the concise
setup path needed to reach the tested state.
- Acceptance criteria: ordered, visually verifiable jobs to be done. Aim for
5–15 criteria per scenario.
Each criterion must be specific, unambiguous, goal-scoped, and observable on
the screen. Bundle an action with its expected visible result. State what to
accomplish and observe, not the exact tap sequence Mini should follow.
Do not use Given/When/Then, micro-steps, internal routes, code identifiers,
component names, implementation details, long hardcoded marketing copy, or
invisible backend assertions. Never put credentials or profile-specific values
in user-facing fields; refer to the bound persona's credentials abstractly.
Scenario types
Every scenario has a type:
- Prefer a built-in type when the primary purpose matches
login,
registration, checkout, onboarding, search, settings, navigation,
form, or profile.
- Otherwise query current custom types, reuse or create a generic reusable
type, and set both
type: "custom" and its real custom-type ID.
- Do not use
other for a recognizable product capability.
- Never invent IDs, use custom without a custom-type ID, or attach a custom ID
to a built-in type.
Personas
A test profile, called a persona in the UI, represents one user identity and
state. Every scenario must bind at least one persona. If none is supplied, the
system binds the immutable New user persona.
Use New user for genuine first-launch, guest, registration, and anonymous
journeys. It receives a unique disposable @qa.minitap.ai inbox and may proceed
anonymously where the app allows it. Do not create duplicate guest personas or
assume it must sign in.
Create a distinct persona for every role, tier, permission level, or returning
state that changes visible behavior. Name personas after the app's real roles.
Describe required state and entitlements in the about field. For tiered apps,
identify hard paywalls that fully block a feature and soft paywalls that can be
dismissed or bypassed.
For generated identities, use a descriptive passwordless @qa.minitap.ai
address so Mini can complete OTP flows. Do not invent passwords or use an
unreadable domain. When a persona needs a pre-provisioned state such as a paid
subscription, use an explicit @qa.minitap.ai email and password and ask the
user to create that account in the required state. Use customer-owned real
credentials only when they provide them.
For Google sign-in, link the existing Shared by Minitap account pool. Do not
invent static Google credentials; Mini leases an account and obtains its 2FA
code at runtime.
Bind personas whose state matches the scenario. Create a dedicated persona if
no existing one does. Set a default persona only when one identity is clearly
the normal starting point for most new scenarios.
Personas and device count
A persona is an identity; a device is a testing surface. They are independent.
An unset device count uses auto: one device per bound persona, with a minimum of
one. An explicit count overrides auto up to the lower of three and the tenant's
quota.
Use multiple devices only when identities must be live simultaneously, such as
real-time messaging, calls, presence, typing indicators, cross-account
visibility, or a notification one account triggers for another. Sequential
identity changes use one device and sign in and out; explicitly set the count to
one on multi-persona sequential scenarios because auto would allocate one per
persona. A same-account session-conflict scenario may bind one persona and use
two devices.
For ordinary single-persona scenarios, leave device count unset. Additional
devices change both cost and behavior and must never be used as speculative
coverage.
Dependencies
Dependencies never replace self-contained setup. They exist only for:
- Fail-fast: skip dependents when a foundational scenario critically fails
and no useful signal could come from running them.
- Device reuse: let the engine reuse a warm device as an optimization.
Before adding a dependency, ask:
- Would running the child still produce useful information if the parent
crashed? If yes, leave it independent.
- Can the child cheaply and safely create its required state in its own setup?
If yes, describe that setup and leave it independent. Use a dependency only
for expensive or irreversible state.
Keep irreversible write scenarios isolated. Use one writer per irreversible
resource and serialize reads of produced state behind that writer. Independent
read-only journeys may run in parallel.
Every scenario in a dependency chain must use the same persona and exact
identity. Give each persona its own sign-in root and chain only that persona's
scenarios beneath it. Never change a persona just to make an edge legal.
Dependencies must stay within one app, contain no cycles, and reference real
scenario IDs. An empty dependency list clears all dependencies while an omitted
field leaves them unchanged. The engine resolves dependencies independently per
platform.
Connectivity
Add offline coverage only when the app exposes offline behavior, caching, or
sync. On Android say Offline (wifi off) rather than airplane mode, since
that is the wording the tester recognizes. On web, word it simply as
Offline. iOS runs cannot change connectivity — skip network-toggle criteria
there.
App knowledge
App knowledge is concise orientation injected into every test run. Keep it
under 1000 characters and include:
- the app's purpose, main screens, and navigation structure;
- key roles or personas;
- non-obvious interactions such as swipe-to-delete or long-press-to-edit;
- hard and soft paywalls and how a free user passes a soft wall; and
- major feature-flag or rollout caveats relevant to the modeled scenarios.
App knowledge is not a full specification. Include only information that helps
Mini navigate and test accurately.
