> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clickproof.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Projects & tests

> How projects, tests, and runs fit together.

## 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:

<CodeGroup>
  ```text Sign-up theme={null}
  Open the app, complete the sign-up or onboarding flow, and reach the home
  screen. It passes when the main home screen is visible.
  ```

  ```text Checkout theme={null}
  Add any item to the cart and complete checkout with the test card. It passes
  when an order-confirmation screen appears.
  ```
</CodeGroup>

<Tip>
  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.
</Tip>

## 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.