# 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.

`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](./global-options.md) and the standard [exit codes](./exit-codes.md). 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`](./uip-test-manager-testcases.md#uip-tm-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

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

### Data shape

```json
{
  "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

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

### Data shape

```json
{
  "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

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

### Data shape

```json
{
  "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

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

### Data shape

```json
{
  "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

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

### Data shape

```json
{
  "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`](./uip-test-manager-wait.md) 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

```bash
# 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

```json
{
  "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`](./uip-test-manager-executions.md#exit-codes). See the Related section below for the `wait` and `report` references.
:::

## Related

- [testcases](./uip-test-manager-testcases.md) — create and link the test cases that populate a test set.
- [executions](./uip-test-manager-executions.md) — list and retry executions once a test set has been run.
- [wait](./uip-test-manager-wait.md) — block until a returned `ExecutionId` reaches a terminal state.
- [report](./uip-test-manager-report.md), [result](./uip-test-manager-result.md), [attachment](./uip-test-manager-attachment.md) — post-run artifacts.

## See also

- [Test Manager overview](./uip-test-manager.md)
- [Scripting patterns](./scripting-patterns.md) — CI-friendly patterns for launching and verifying runs.