Test cases

Test cases live as files under tests/ and are managed on the Tests page: on the left the file tree with all test cases, on the right the editor with the opened test case and its Run controls.

The concepts

Six building blocks make up everything you author:

All of it lives in one Project, plain files, shared via Git. A suite frames its test cases with setup, teardown, and rules; how suites nest and scope chains is on Organisation & Scope. Cases and setups call procedures for repeated sequences, and reference secrets instead of containing credentials. Plans select which cases run together.

Create a test case

A test case is one file: preconditions, steps with expected results, postconditions. The file name is the test's name in runs and reports.

1. Right-click in the file tree → New Markdown (or New CSV).
2. Name the file and fill the seeded template. How to phrase steps well: Writing good tests.

The same menu holds everything on this page: creating files and folders, the quick-create entries for setup / teardown / rules, Run on, and Duplicate / Rename / Delete.

Anatomy & formats

Every test case has the same three parts, preconditions, steps, postconditions, whatever the file format:

# Login Flow · Smoke Test

## Preconditions
- No user is currently logged in

## Steps
1. Log in using the `login_to_ui` procedure with the QA secrets
2. Wait until the start screen loads

## Postconditions
- Test passes if the signed-in indicator is visible

Test case ID,Test case name,Precondition,Step number,Step description,Expected result
LOGIN_001,Valid login,App is open on the login screen,1,Enter the QA credentials into the login form,Both fields are filled
,,2,Click the Login button,The start screen is visible and the user is signed in

{
  "id": "LOGIN_001",
  "name": "Valid login",
  "preconditions": ["App is open on the login screen"],
  "steps": [
    { "action": "Enter the QA credentials into the login form", "expected": "Both fields are filled" },
    { "action": "Click the Login button", "expected": "The user is signed in" }
  ]
}

Preconditions: the state the test assumes, not work to perform: which screen is open, which user is logged out, which data exists. The agent checks them before the first step and records whether they were met; a test whose preconditions aren't met is reported SKIPPED instead of producing a misleading step failure, because it never ran. Shared preparation work belongs in setup, not here.

Steps: numbered actions, each paired with what to expect. The agent executes them one at a time: perform the action, compare what it observes against the step's expected result, record both with a screenshot. Each step becomes an expected-vs-actual entry in the run report, so a step without an expected result is a step the report can't judge. Everything a step can express, conditions, waits, checks, procedure calls, is on Step constructs.

Postconditions: the overall pass criterion, phrased as a checkable end state: "Test passes if …". The agent judges it after the last step, independent of which path it took to get there. The case's reported status is the worst of its steps (how it is derived).

These templates are starting points, not schemas, the agent reads a test the way a tester would, so you're free to choose your own structure. .md holds one case per file, .csv one case per row (data-driven testing), and .json, .txt, or .pdf exports from a test-management tool run as-is. New to Markdown? The Markdown Guide covers the syntax in ten minutes.

Target multiple platforms

A first line platforms: desktop, android marks a case cross-platform, it then runs only on a Cross-platform profile, and single-platform tests never run there. The steps name the surface, like a multi-computer test names machines.

Use secrets in a test

Never write credentials into a case, reference named secrets by name instead. Add the value once under Utils → Secrets; the agent sees only the name, and the real value is substituted at execution time, redacted from logs and reports:

Sign in with the QA credentials — the secrets named
`QA_USERNAME` and `QA_PASSWORD`.

Run a test case

1. Pick a connected device in Run on.
2. Press Run, or right-click any file or folder → Run on → a profile.

Details in Running a test.

Manage a test case

All of it is plain file operations via right-click, visible in Git like any other change to your testware.

Duplicate

1. Right-click the file → Duplicate.
2. Rename the copy, it's the starting point for a similar case.

Rename

1. Right-click the file → Rename.
2. Enter the new name. The file name is the test's name in runs and reports; reports of old runs keep the old name.

Delete

1. Right-click the file → Delete.

Skip

There is no skip flag: to leave a case out temporarily, run a plan that doesn't include it, or move the file out of tests/.