uipath-test

name: uipath-test description: "UiPath Test Manager — manage test projects, cases, sets, executions; generate reports. For Orchestrator→uipath-platform. For test automation→uipath-rpa." allowed-tools: Bash, Read, Write, Glob, Grep user-invocable: true

UiPath Test Assistant

Manage UiPath Test Manager resources (projects, test cases, test sets, executions) and generate persona-tailored shareable test reports.

When to Use This Skill

• User wants to list, create, update, delete Test Manager projects, test cases, test sets, or executions
• User wants to view or analyse test execution results
• User wants to generate a shareable test report tailored to a QA engineer, developer, or release manager
• User asks about test coverage, regression trends, or failure rates
• User needs a go/no-go decision summary based on recent test executions

Concepts

What is Testmanager?

UiPath Test Manager is a web application that manages the testing lifecycle of projects, enabling requirements traceability, test planning, and reporting. Its key business objects are:

• Requirements - Defines what needs to be tested.
• Test cases - Defines the scenarios to be tested. A testcase can have teststeps. A testcase can be executed or run directly.
• Test sets - Groups of test cases for execution.
• Test executions - When a test set or a test case is run, a test execution is created.
• Test case logs - Logs of a test case in an execution. A testcase can be navigated from testcaselogs.
• Test step logs — Step-level logs within a test case log.
• Test case log assertions - Assertion steps of a test case log in an execution.

CLI tool for UiPath Test Manager (uip tm). Use uip tm --help and uip tm <command> <subcommand> --help to discover commands and options. Always pass --output json on every uip command.

Commands

Common uip tm commands organized by resource type.

Project Commands

Get folder keys with uip or folders list -n <name> --all --output json — returns all folders visible to the current user.

Requirements Commands

Test Cases Commands

Three flag shapes for test case identifiers — do not interchange:

• --test-case-id <UUID> — used by run, list-steps, list-result-history. Get the UUID from uip tm testcases list --output json (Id field).
• --test-case-key <PROJECT_KEY:NUMBER> — singular, used by update, delete, link-automation, unlink-automation, list-testsets. Example: DEMO:1.
• --test-case-keys <KEY1,KEY2,...> — plural, comma-separated, used by testcases add and testcases remove for bulk membership changes on a test set.

Test Sets Commands

Keys use the format PROJECT_KEY:NUMBER (e.g., INV:42). To add or remove test cases in a test set, use uip tm testcases add / uip tm testcases remove — those verbs live under the testcases group, not under testsets.

Executions Commands

run lives under three groups, all distinct:

• uip tm testcases run — start a new execution for one or more test cases (--test-case-id UUIDs, space-separated).
• uip tm testsets run — start a new execution for an entire test set (--test-set-key).
• uip tm executions run — re-run an existing execution by --execution-id, optionally narrowed to specific --test-case-log-ids.

Test Case Log Commands

Test Step Log Commands

Report Commands

Attachment Commands

Result Commands

Wait Commands

User Commands

Custom Field Commands

Custom fields are project-scoped field definitions you attach to Requirement, TestCase, or TestSet objects. The top-level customfield commands manage these definitions. The nested label and value subgroups operate on the per-object rows that fill in those fields. The --object-type flag is case-sensitive and accepts only Requirement, TestCase, or TestSet. The --data-type flag accepts only Text or Label (also PascalCase).

Custom Field — Label-type rows

All customfield label verbs require --object-type <Requirement\|TestCase\|TestSet>.

Custom Field — Text-type rows

All customfield value verbs require --object-type <Requirement\|TestCase\|TestSet>. create additionally requires --data-type <Text\|Label> (must match the field's definition).

Object Label Commands

Object labels are tag-style metadata applied to Requirement, TestCase, TestSet, TestExecution, TestCaseLog. Use --object-type for the parent kind and --object-ids for the target objects.

Critical Rules

1. Always check login first — run uip login status --output json before any Test Manager operation. If not authenticated, run uip login to sign in.
2. Probe the CLI surface once per session, before the first uip tm command. Run uip tm testcases --help --output json (any flags accepted). Result Success → post-rename CLI; use the command tables above as-is. unknown command / non-zero exit → pre-rename CLI; translate via the Pre-rename fallbacks table before each call. Re-probe on any later unknown command error.
3. Always pass --output json to every uip command — no exceptions. Structured JSON output is what you need to reason about results reliably, even when you only plan to summarize them back to the user.
4. Cap retries at 3 for any failing uip CLI command. After 3 failures, stop and report the error to the user (see Rule — never fall back to direct REST APIs).
5. Handle empty results — if a list command returns an empty array, stop and inform the user rather than proceeding with a null key.
6. Confirm before delete — always confirm the target resource key with the user before running any delete command.
7. For operations requiring folder key — use uip or folders list -n <folder-name> --all --output json (run /uipath-platform for folder management details).
8. Discover before assuming — never guess automation names, folder keys, project IDs, or test case keys. Always run the matching list command first (e.g., uip tm testcases list-automations, uip or folders list -n <folder-name> --all).
9. Narrow list calls server-side when the user names an entity. When the user provides a name, key, label, or tag, check uip tm <resource> list --help (or uip or <resource> list --help) for the narrowing flag the command exposes and pass it on the list call. Never list all results and filter client-side — it wastes tokens and misses paginated entries. Applies to every entity across uip tm and uip or.
10. Set default folder before any run command — uip tm testcases run and uip tm testsets run both require a default Orchestrator folder on the project. Run uip tm project set-default-folder --project-key <PROJECT_KEY> --folder-key <FOLDER_KEY> --output json first. Get folder keys with uip or folders list -n <folder-name> --all --output json.
11. On any uip command failure or ambiguity, STOP and ask the user — do NOT fall back to direct REST API calls. When a uip command errors, returns malformed output, or the right flag/value is unclear (e.g., multiple matching entities, missing identifier, unexpected schema), interrupt and ask the user before proceeding. This overrides any instinct to "try the underlying API instead."

Pre-rename fallbacks

If the probe in Rule #2 shows singular subjects, the CLI predates the closed-verb-set renames. Translate before running:

uip tm wait, tm testcaselog, tm report, tm result, tm attachment, tm project, tm user, tm requirement are unchanged on both surfaces.

Quick Start

Verify authentication

uip login status --output json

If not authenticated, run uip login to sign in.

Set the active tenant (if needed)

uip login tenant set <TENANT_NAME> --output json

For more authentication details, run /uipath-platform.

Confirm project scope

Ask the user for the project name or key before any Test Manager call. For multi-project scenarios, collect ALL names or keys in one prompt. Resolve each to a PROJECT_KEY:

uip tm project list --filter <NAME_OR_KEY> --output json

Zero matches → stop and ask the user. Multiple matches → list candidates and ask the user to pick. Reuse the confirmed PROJECT_KEY for every downstream command.

  # Get project
  uip tm project list --filter <PROJECT_NAME_OR_KEY> --output json

  # List test sets in a project
  uip tm testsets list --project-key <PROJECT_KEY> --filter <TEST_SET_NAME_OR_KEY> --output json

  # List test cases assigned to a test set
  uip tm testsets list-testcases --project-key <PROJECT_KEY> --test-set-key <TEST_SET_KEY> --output json

  # List recent executions for a test set
  uip tm executions list --project-key <PROJECT_KEY> --test-set-id <TEST_SET_ID> --limit 100 --output json

  # List test case logs for an execution (nested subcommand under `executions`)
  uip tm executions testcaselogs list --execution-id <EXECUTION_ID> --project-key <PROJECT_KEY> --output json

  # List assertions of a test case log
  uip tm testcaselog list-assertions --project-key <PROJECT_KEY> --test-case-log-id <TEST_CASE_LOG_ID> --output json

  # List step-level logs of a test case log
  uip tm teststeplog list --project-key <PROJECT_KEY> --test-case-log-id <TEST_CASE_LOG_ID> --output json

Troubleshooting

If a command fails unexpectedly:

1. Verify the command syntax: uip tm <command> --help
2. Check authentication: uip login status --output json

Navigate to a workflow

Anti-patterns

• Do NOT proceed if authentication fails — all Test Manager API calls require a valid bearer token. Fail fast rather than surfacing confusing 401 errors later.
• Do NOT skip the surface probe (Critical Rule #2). On a pre-rename CLI, post-rename commands fail with unknown command; on a post-rename CLI, pre-rename commands fail the same way. The skill targets the post-rename surface and falls back per the Pre-rename fallbacks table. Picking the wrong shape without probing burns a retry on every call.
• Do NOT guess command names — verb-noun composites are required. The CLI uses explicit verb-noun forms; bare verbs do not exist. Confirm with uip tm <resource> --help --output json.