uip tm testsets

uip tm testsets manages test sets: the executable unit in Test Manager. A test set is an ordered group of test cases that you can run with one command and track as a single execution. Every testsets run call returns an ExecutionId that the other uip tm verbs (wait, executions, report, result, attachment) take as input.

Synopsis

uip tm testsets create --project-key <key> --name <name> [--description <text>]
uip tm testsets list --project-key <key> [--folder-key <uuid>] [--filter <text>]
uip tm testsets update --test-set-key <key> [--name <name>] [--description <text>]
uip tm testsets delete --test-set-key <key>
uip tm testsets list-testcases --test-set-key <key>
uip tm testsets run --test-set-key <key> [--execution-type <type>] [--input-path <file>]

All verbs honor the global options and the standard exit codes. Every verb accepts -t, --tenant <name> and --log-level <level> (default Information).

Test set verbs that take --test-set-key derive the owning project from the key's prefix (e.g. DEMO:10 → project DEMO), so --project-key is only required on create and list.

uip tm testsets create

Create an empty test set in a project. Use testcases add afterwards to populate it.

Arguments: none.

Options:

• --project-key <key> (required) — owning project.
• --name <name> (required) — test set name.
• --description <text> — free-form description. Defaults to empty.

Example:

uip tm testsets create \
  --project-key DEMO \
  --name "Smoke Suite" \
  --description "Core smoke tests"

Data shape:

{
  "Code": "TestSetCreate",
  "Data": {
    "TestSetKey": "DEMO:10",
    "Name": "Smoke Suite",
    "Description": "Core smoke tests"
  }
}

uip tm testsets list

List test sets in a project. The CLI pages through results automatically.

Arguments: none.

Options:

• --project-key <key> (required) — project to list.
• --folder-key <uuid> — restrict to test sets bound to this Orchestrator folder. Applied client-side after fetching.
• --filter <text> — server-side search over name.

Example:

uip tm testsets list --project-key DEMO --filter smoke

Data shape:

{
  "Code": "TestSetsList",
  "Data": [
    {
      "TestSetKey": "DEMO:10",
      "Name": "Smoke Suite",
      "FolderKey": "f0f0f0f0-0000-0000-0000-000000000001",
      "Id": "a1b2c3d4-0000-0000-0000-000000000010"
    }
  ]
}

Id is the internal UUID — needed, for example, by execution list --test-set-id.

uip tm testsets update

Rename a test set or change its description. At least one of --name or --description must be supplied.

Arguments: none.

Options:

• --test-set-key <key> (required) — test set key (e.g. DEMO:10).
• --name <name> — new name.
• --description <text> — new description.

Example:

uip tm testsets update \
  --test-set-key DEMO:10 \
  --name "Smoke Suite (2026)"

Data shape:

{
  "Code": "TestSetUpdate",
  "Data": {
    "TestSetKey": "DEMO:10",
    "Name": "Smoke Suite (2026)",
    "Description": "Core smoke tests",
    "Result": "Updated"
  }
}

uip tm testsets delete

Delete a test set by its key.

Arguments: none.

Options:

• --test-set-key <key> (required) — test set key.

Example:

uip tm testsets delete --test-set-key DEMO:10

Data shape:

{
  "Code": "TestSetDelete",
  "Data": {
    "TestSetKey": "DEMO:10",
    "Id": "a1b2c3d4-0000-0000-0000-000000000010",
    "Result": "Deleted"
  }
}

uip tm testsets list-testcases

List the test cases assigned to a test set.

Arguments: none.

Options:

• --test-set-key <key> (required) — test set to inspect.

Example:

uip tm testsets list-testcases --test-set-key DEMO:10

Data shape:

{
  "Code": "TestSetTestCasesList",
  "Data": [
    {
      "TestCaseKey": "DEMO:1",
      "Name": "Login smoke",
      "Version": "1.0.0",
      "Description": "Logs in and out"
    }
  ]
}

uip tm testsets run

Run a test set and return its ExecutionId immediately. The test set itself must already be configured with a package and folder — either by authoring inside Test Manager's web UI, or by hand via the REST API. Run does not block; pair it with uip tm wait in scripts.

Arguments: none.

Options:

• --test-set-key <key> (required) — test set to run. The project key is derived from the prefix.
• --execution-type <type> — which test cases to run. One of:
  • automated (default) — only automated test cases.
  • manual — only manual test cases.
  • mixed — both automated and manual.
  • none — no type filter.
• --input-path <file> — path to a JSON file of parameter overrides. The file must contain an array shaped like [{"name":"Param","type":"String","value":"v"}]. Overrides are matched against the test set's current parameter definitions by name (and, when present, type), case-insensitive. If the server reports no parameter definitions, the inputs are sent as-is.

Examples:

# simplest
uip tm testsets run --test-set-key DEMO:10

# with parameter overrides and manual execution
uip tm testsets run \
  --test-set-key DEMO:10 \
  --execution-type mixed \
  --input-path ./params.json

Data shape:

{
  "Code": "TestSetRun",
  "Data": {
    "ExecutionId": "a1b2c3d4-0000-0000-0000-000000000001",
    "TestSetKey": "DEMO:10",
    "Status": "Running",
    "StartTime": "2025-04-15T10:30:00Z"
  }
}

Note:

The returned Status reflects the state at launch (typically Running); it does not mean the run has succeeded. To get the run outcome, block on uip tm wait and then read uip tm report get. Exit-code behavior for the combined launch-and-wait flow is documented on uip tm executions. See the Related section below for the wait and report references.

Related

• testcases — create and link the test cases that populate a test set.
• executions — list and retry executions once a test set has been run.
• wait — block until a returned ExecutionId reaches a terminal state.
• report, result, attachment — post-run artifacts.

See also

• Test Manager overview
• Scripting patterns — CI-friendly patterns for launching and verifying runs.