- Overview
- Get started
- Concepts
- Using UiPath CLI
- How-to guides
- CI/CD recipes
- Command reference
- Overview
- Exit codes
- Global options
- uip codedagent
- uip docsai
- add-test-data-entity
- add-test-data-queue
- add-test-data-variation
- analyze
- build
- create-project
- diff
- find-activities
- get-analyzer-rules
- get-default-activity-xaml
- get-errors
- get-manual-test-cases
- get-manual-test-steps
- get-versions
- get-workflow-example
- indicate-application
- indicate-element
- inspect-package
- install-data-fabric-entities
- install-or-update-packages
- list-data-fabric-entities
- list-workflow-examples
- pack
- restore
- run-file
- search-templates
- start-studio
- stop-execution
- uia
- uip traces
- Migration
- Reference & support
UiPath CLI user guide
uip tm is the Test Manager tool: it manages test projects, test cases, test sets, executions, results, reports, and attachments on a UiPath Test Manager tenant. Install it with uip tools install tm, or invoke uip tm … and let auto-install run. See Tools (plugins) for the install model and uip tools for the command that manages tool installation.
tm is the command prefix — never uip test-manager. Use the commandPrefix column from uip tools list to confirm.
Resources
Each resource has its own reference page. The verb set on each page matches the commands registered by uip tm — run uip tm --help to confirm the full surface on your installation.
| Resource | Purpose |
|---|---|
| project | Create, list, update, delete Test Manager projects; set or clear the default Orchestrator folder. |
| testcase | Create, list, update, delete test cases; link or unlink Orchestrator automations; list result history; list test sets that contain a test case. |
| testset | Create, list, update, delete test sets; add or remove test cases; list contained test cases; execute a test set and return an execution ID. |
| execution | List executions for a test set; list test case logs for an execution; retry the failed test cases of a finished execution. |
| result | Download the results of a test execution as a JUnit XML report. |
| report | Get a summary report (counts, pass rate, duration, failed cases) for a completed execution. |
| attachment | Download attachments (screenshots, logs, files) captured by test case logs in an execution. |
| wait | Poll a test execution until it reaches a terminal state; returns a non-zero exit code on timeout. |
tm testcaselog list-assertions lives on the test case page — see testcase. It is registered as a separate testcaselog subcommand at runtime, but documented with test cases because it reads the assertion artifacts attached to a test case log.
Synopsis
uip tm <resource> <verb> [options]
uip tm <resource> <verb> [options]
Default output is --output json. All uip tm verbs honor the four global options (--output, --output-filter, --log-level, --log-file).
Typical flow
Test Manager resources form a chain. A full CI run normally walks it end to end:
- project — one-time setup. Create the project (or reuse an existing one), and optionally pin a default Orchestrator folder so later commands can omit
--folder-key. - testcase — author test cases and link each one to an Orchestrator package entry point with
testcase link-automation. This is the step that makes them runnable. - testset — group test cases into an executable suite with
testset createfollowed bytestset add-testcases. - testset execute — start a run. Returns an
ExecutionIdthat every downstream command takes as input. - wait — block the script until the execution reaches a terminal state (
Passed,Failed,Cancelled). Use--timeoutto cap the wait. - report / result / attachment — after the run: a structured summary (
report get), a JUnit XML file for CI test dashboards (result download), and any captured artifacts (attachment download). - execution retry — optional: if the run had failures that may be flaky, re-run only the failed test case logs in place.
The same flow works ad-hoc at a terminal: each verb prints a self-contained JSON envelope with the IDs the next step needs.
Authentication and scope
Every uip tm verb resolves tenant and project context through the active session. See Authentication for sign-in; the --tenant / -t flag on every verb overrides the session default for that one call. Project scope is resolved from --project-key (or derived from --test-set-key on execution-level verbs that accept either).
Exit codes
Standard CLI exit codes apply to every verb. One verb adds domain-specific behavior:
uip tm testset executefollowed byuip tm wait— see Exit codes on execution.waitexits2on timeout, so a script can branch on timeout vs. finish-with-failures vs. clean pass without parsing JSON. Test-failure detection itself happens viareport getorresult download, not via the execute command's exit code.
See also
- Concepts: how UiPath CLI is organized
- Sessions — how tenant and project context are resolved.
- Scripting patterns — exit-code branching and JSON filtering for CI.
- Output formats — JSON envelope and
--output-filter.