Skip to main content
A fixture is the state your app is in before a check’s steps begin: signed in, a cart with two items, a clean install. You write it once in .mobster/fixtures/ and name it in each check that needs it.

What a fixture holds

A sign-in uses the project’s secrets: ${TEST_EMAIL} and ${TEST_PASSWORD} come from mobster env (Checks), are filled in when the run starts, and never reach a report. Fixtures compose in the order you name them. reset and nonempty pasteboard take the last one set. Keychain resets accumulate. args and steps add up. env and a file’s destination are replaced by a later fixture. A fixture used twice runs once, and a circle (a extends b extends a) is refused with the chain.

List and apply

mobster fixtures apply does the same to a simulator now, without a check: it resets the app, resets the keychain, copies the files and sets the pasteboard. It doesn’t launch the app, and it leaves a fixture’s args, env and steps for a check to use. Run on 18 Oct 2026 on an iPhone 17 Pro simulator (iOS 26.4):
cat of the file in the app’s container then read {"items": 2}, and xcrun simctl pbpaste read SAVE10. The first run on a simulator also builds WebDriverAgent, which took 92 s that day. --json prints the list as JSON, and GET /api/tests/fixtures?project=/abs/path returns it to the Mac app: each fixture’s flattened reset, args, env, steps, files, keychain, destructive, and whether a pasteboard is set (never its text).

What it won’t do to your iPhone

A reset, seed files, a keychain reset and a pasteboard change a device’s state, so they run on simulators only. A check on a real iPhone whose fixture holds any of them doesn’t run, and says why before it touches the phone:
On a phone, args, env and steps work, so a sign-in fixture runs there. Files go only inside the app’s data container on a simulator Mobster made. A destination that leaves the container, a symbolic link in the way, a source outside .mobster/fixtures/ and more than 20 MB are refused, and nothing is copied.