Test cases and runs

Write test cases whose steps are versioned, run them in batches, record results that pin the steps they exercised, and read coverage.

Last updated 2026-10-10

Test management in Rindo is small on purpose. A test case says what to do and what to expect; a run is a fixed batch of cases; a result is what one case did in one run. There are no plans, suites or folders. The Tests tab is in the project when its template included the tests module.

A test case

Choose New test case and give it a title, an optional component, and an Expected result — a short plain-text note saying what a passing run observes. The case opens and you write its Steps.

The steps are a versioned page, like a task’s description: every edit is a revision, History shows the chain with who changed what, and a revert makes a new revision rather than rewriting one. The title, the expected result and the status are plain fields — the status from its pill, the title and the expected result from … › Edit — recorded on the audit trail, with no revision history.

Every case has a key, TC- and a number, counted across the whole of app.rindo.io rather than per project — the handle the CI import matches on.

Status

A case is born Draft. Change its status from the pill on the case page — any status may move to any other:

• Draft — may be included in a run; running a draft is how you decide whether to keep it.
• Active — the only status that counts: coverage and a release’s readiness read Active cases and nothing else.
• Deprecated — kept for its history; cannot join a new run.

Links, watching, comments

Link tasks from the case page with Link task; the task page lists its cases with each one’s latest result. Watch a case to hear about its comments, steps revisions and status changes in your Inbox. Cases take comments and attachments like tasks do.

Agents and drafts

A project agent that writes steps — a new case, or an edit to one — always submits them as a pending draft: the cases list carries a violet dot (Pending steps draft — awaiting review), the case page a ribbon, and a Member approves or rejects in History. Unlike a task, even a new case’s first steps wait for approval. Your own assistant over MCP writes steps directly unless Content writes via MCP require approval is on under the project’s Agent writes settings. Title, expected result and status land directly on every channel — an agent may mark a case Active. See Review what your AI proposes.

Runs

Open Runs and choose New run: a name, an optional Build (free text, say 1.9.0-rc1), and the cases to include, up to five hundred — deprecated cases are listed but cannot be picked. Every case in the run starts Pending.

A run is a fixed batch. Cases cannot be added later, a run is never closed and never deleted, and the build is the one field you can still edit. To test again, create a new run from the same cases. Results from a CI pipeline arrive through Import — see Import test results from CI.

Recording a result

On the run page each case has Record: choose Pass, Fail, Skip or Blocked, add a note (recommended for a fail or a block), and submit.

Recording pins the steps revision the result exercised — the row reads tested r7 — and keeps pointing at it however the steps change afterwards; steps now r9 appears beside it as a cue. Re-record overwrites the row and pins the current revision (an identical re-record changes nothing); the audit trail keeps the earlier result. Nothing sets a result back to Pending.

Agents record the same way, through the same tools; the row names who recorded it, and marks a person’s MCP recording via MCP. The runs list sums each run — 3 pass · 1 fail · 2 pending.

Wherever Rindo shows a case’s latest result — the cases list, coverage, a release’s readiness — it is the most recent recorded result across every run the case was in.

Coverage

The Coverage view reads N of M tasks covered: every task in the project, and a task is covered when at least one Active case is linked to it, whatever that case’s result. Among the tasks loaded so far, uncovered ones are grouped first; each covered one shows its cases with their latest results.

Covered is not passing. Whether the linked cases pass is what a release’s readiness answers — see Releases and readiness.

Deleting a case

An Admin deletes a case from its … menu, in the app only; it moves to the project’s Trash, from which it can be restored for the number of days the Trash page states. Its recorded results stay while it is there — in a run the row reads deleted and can no longer be recorded — and go with it when it is purged.

Over MCP

An assistant or agent can create and update cases, list them with their latest results, create runs, record results, and read runs. It cannot delete or restore a case; nobody reverts steps over MCP, and a project agent cannot approve or reject a draft either; a run’s build is set in the app or over REST, and CI results come in over REST with a token — see Import test results from CI. Tasks are linked to a case at creation over MCP, afterwards from the case page.

Who can do what