Skip to main content

​
Projects

A project represents one product on one surface. You choose which when you create it: A project is one kind or the other and cannot be switched, because a test written against a phone screen does not describe a desktop browser. A team with a website and an app wants two projects, and that is the intended shape rather than a limitation to work around. For a mobile project, which device a run uses is decided when the run starts: with builds for both platforms the test page offers a choice, and 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 works out the individual actions at run time. This is identical on both surfaces - the same sentence describes a checkout whether it happens in Chromium or on a Pixel. 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, so a failure points at one thing rather than somewhere inside a twenty-step epic.
Say what proves the test passed, not just what to do. “Complete checkout” leaves the agent to guess what success looks like; “an order number is visible” does not. This matters more than any other thing you can change about a test.

​
Runs

A run is one execution of a test - against a build on a mobile project, or against the project’s URL on a website project. 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, which is what CI does by default. Statuses: queued → running → one of passed, failed, error, or cancelled. failed and error mean different things. Failed is a verdict: the agent finished and your app did not do what the test said it should. Error is the run itself not completing - a browser that would not start, a build that would not install, a run that hit its time budget. A failed run is a finding; an errored run is usually something to retry.

​
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 are encrypted at rest and never appear in reports, in the agent’s trace, or in the guidance carried over from a previous run. This works the same on both surfaces.