Projects
A project represents one app. It owns that app’s builds and its tests, and
it can hold builds for both Android and iOS: the same product, the same
tests, the same history. Create one project per app you want to test, not one
per platform.
Which device a run uses is decided when the run starts. If the project has
builds for both platforms, the test page offers a choice; with one build it
simply uses that one.
Tests
A test is a goal written in plain English — clickproof generates the plan and
the agent figures out the taps at run time. Good tests describe an outcome and a
clear pass condition:
Keep each test focused on a single flow with one clear success condition. Split
long journeys into several tests — they run in parallel and report separately.
Runs
A run is one execution of a test against a build. Every run produces a status,
the agent’s step-by-step trace, and a video recording. A project’s tests can all
be run together as a suite (that’s what CI does by default).
Statuses: queued → running → one of passed, failed, error, or
cancelled.
Credentials
If a flow needs a login, store credentials on the project so the agent can sign
in without you hard-coding them into a test. They’re encrypted at rest and never
appear in reports.