Skip to main content
A project represents one website under test. Everything else in Testorim belongs to a project: its runs, its procedures, its environments, its variables, its schedules, its Slack channel, its GitHub repository.

​
Creating one

On the home page, type the site’s address into the address field, give the project a name if you like (it defaults to the address), and press Start.
  • https:// is already supplied, so type shop.example.com, not the scheme. Paste an http:// address and the field switches to http://.
  • If the workspace already has a project for that address, Testorim asks whether to open it rather than creating a duplicate.
  • A new project opens on its Test tab, with a short “Help Testorim understand this app” form. A few facts about the app (what it is, how sign-in works, the key flows) help the planner write better steps. Keep it high level: no passwords or customer data.
The address you give becomes the project’s base address. Every run starts there, and a step that navigates to a relative path (/checkout) resolves against it.
Private and internal addresses are refused: localhost, loopback, RFC1918 ranges, link-local and cloud metadata endpoints, including a name that resolves to one. The guard applies twice: once when you save the address, and again to every connection the page makes during a run. Expose a local build through a tunnel and use the public URL.

​
The project’s tabs

Every project has five tabs under the app header.

​
The overview

The overview shows:
  • Stats: runs in the last 30 days, pass rate, number of procedures, last run
  • Procedures: the five most recently used, each with a Run button that opens the Test tab
  • Recent runs: the five latest, with their verdict
  • Flakiness: pass rate per procedure, worst first, once there are 30 days of data
  • Recent PR activity: only when a GitHub repository is linked
  • Integration chips: a row under the address showing what is set up: repository, Slack channel, email alerts, schedules, environments, fixtures, databases, variables, and login reuse once a login is saved. Each one jumps to its setting. Missing GitHub, Slack or email alerts show as one “Connect…” link.

​
Settings

Project settings has one section per page, grouped: Account-wide settings live under /settings/<section>: Workspace (members and invitations), API keys, Billing and usage and Preferences.

​
Reusing a login

If you save a sign-in flow as a procedure and mark it as the project’s Login setup procedure, a successful run captures the browser’s session and encrypts it onto the project. Later runs start already signed in and skip the login flow. See Reusable flows.

​
Deleting a project

Deleting a project removes it from every list and page. Runs still in flight are cancelled, its share links stop working, and its schedules stop. Its runs are kept on our side as the billing record, and still count toward the period’s usage, but they are no longer shown anywhere.

​
Who can do what

Projects belong to a workspace, and every query is scoped to it. A project in one workspace is invisible from another, and asking for it by id returns not found rather than forbidden. If you belong to the workspace that holds it, the app offers to switch. Each browser tab keeps its own workspace, so two tabs can show two workspaces at once. Nobody can grant, change or remove a role above their own, and the last owner can never be demoted or removed. Anyone except the last owner can leave a workspace.