Study guide
16.1 UiPath Test Suite Overview, Test Cases & Given-When-Then Structure
UiPath Automation Developer Professional UiPath-ADPv1
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Blueprint Map
1.1 About the UiPath-ADPv1 Exam: Format, Fees & Policies 1.2 The Exam Topics Mapped to This Guide & a Study Plan
2 Chapter 2: REFramework Architecture & State Dynamics
2.1 State Machine Architecture & The Four Core States 2.2 Configuration Management: Settings, Constants, and Assets 2.3 Transaction Types & The Dispatcher vs. Performer Architecture 2.4 Adapting REFramework: Tabular Data, Collections & Linear Processes
3 Chapter 3: REFramework Exception Handling & Recovery
3.1 BusinessRuleException vs. System.Exception Handling Patterns 3.2 Retry Mechanisms: Queue Retries vs. REFramework MaxRetryNumber 3.3 Consecutive System Exceptions & Graceful Process Termination
4 Chapter 4: State Machines, Custom Log Fields & REFramework Testing
4.1 Building State Machine Projects in Studio 4.2 Logging Levels, Robot Logs & Custom Log Fields in REFramework 4.3 Testing a REFramework Project With and Without Orchestrator Queues
5 Chapter 5: LINQ Queries & DataTable Operations
5.1 LINQ Essentials for Collections & Filtering 5.2 Advanced DataTable Querying with LINQ 5.3 In-Memory DataTable Transformations & Column Operations
6 Chapter 6: Regex, DateTime, JSON & Invoke Activities
6.1 Regular Expressions & Text Parsing for Automation 6.2 DateTime Formatting, Timezone Conversions & TimeSpan Calculations 6.3 JSON Parsing, JSONPath & Serialization with Newtonsoft.Json 6.4 Invoke Method & Invoke Code Activities 6.5 Data Referencing in Invokes: DataTable, List & Dictionary Arguments
7 Chapter 7: Modern UI Automation & Unified Targeting
7.1 Modern Design Experience & The Unified Target Concept 7.2 Anchors, Relative Elements & UI Automation Activities 7.3 Dynamic Selectors, Variables & Wildcards in Selectors
8 Chapter 8: Object Repository, Computer Vision & Remote Runtime
8.1 Object Repository & UI Descriptor Libraries 8.2 AI Computer Vision for Unattended & Remote Interfaces 8.3 Automation in Virtual Environments & UiPath Remote Runtime
9 Chapter 9: Advanced UI Automation: Browser Modes, Agentic UI & macOS
9.1 Browser Automation with the WebDriver Protocol 9.2 Agentic UI Automation: ScreenPlay, Semantic Activities & Healing Agent 9.3 macOS Automation: Native Apps, Office Apps & AppleScript
10 Chapter 10: Advanced Control Flow & Exception Architecture
10.1 Flowcharts, Sequences & Parallel Control Flow Patterns 10.2 Global Exception Handler Architecture & ErrorAction Directives 10.3 TryCatch, Retry Scope & Custom Exception Architectures
11 Chapter 11: Orchestrator Queues & Transaction Management
11.1 Queue Architecture, SpecificContent & Transaction Lifecycles 11.2 Queue Items SLA, Postpone, Deadlines & Priority Scheduling 11.3 Bulk Operations, Transaction Status Updates & Queue Triggers
12 Chapter 12: Orchestrator Tenant & Folder Entities
12.1 Asset Types, Per-Robot Assets & External Credential Stores 12.2 Modern Folder Hierarchy, User/Robot Assignment & Permissions 12.3 Storage Buckets, Webhooks & Environment Promotion 12.4 Orchestrator Tags: Labels, Properties & Governance
13 Chapter 13: Unattended Execution, API Triggers & Cloud Robots
13.1 Unattended Job Execution: Folders, Priorities, Background vs. Foreground & Runtimes 13.2 API Triggers: Starting Jobs from External Systems over HTTP 13.3 Serverless and Cloud VM Robots: Cloud-Hosted Execution Options
14 Chapter 14: Monitoring, Recording & Solutions Management
14.1 Orchestrator Monitoring, Trigger Alerts & Job Health 14.2 Job and Transaction Recording: Troubleshooting Faulted Unattended Jobs 14.3 Solutions Management: Packaging and Deploying Automations with Their Resources
15 Chapter 15: Debugging, Remote Debugging & Profiling
15.1 Studio Debugging Tools: Breakpoints, Panels & Execution Control 15.2 Remote Debugging: Remote Machine and Unattended Robot Connections 15.3 Profile Execution: Finding Performance Bottlenecks in Studio
16 Chapter 16: RPA Testing & Test Suite
16.1 UiPath Test Suite Overview, Test Cases & Given-When-Then Structure 16.2 Data-Driven Testing, Test Verification Activities & Mock Activities 16.3 CI/CD Pipelines with uipcli & Test Manager Traceability
17 Chapter 17: Long-Running Workflows, Action Center & Apps
17.1 Long-Running Workflows: Persistence, Suspend and Resume 17.2 Action Center & Human-in-the-Loop Orchestration 17.3 UiPath Apps: Action Apps, Automations & Integration Service
18 Chapter 18: Trigger-Based Attended Automation & Callouts
18.1 Trigger-Based Attended Automation: Forms, Triggers & Global Variables 18.2 Running Local Triggers & the Event Inspection Tool 18.3 Callouts & Forms for Attended Guidance
19 Chapter 19: UiPath Assistant & Robot Sessions
19.1 UiPath Assistant: Automations, Reminders, Widgets & Configuration 19.2 Robot Session (Picture in Picture): Child Session vs. Virtual Desktop
20 Chapter 20: Autopilot for Developers & Autopilot for Everyone
20.1 Autopilot for Developers: AI Assistance in Studio and Studio Web 20.2 Autopilot for Everyone: Chat, Automations & Clipboard AI
21 Chapter 21: API Automation & Integration Service
21.1 Integration Service: Connectors, Connections & Connector Activities 21.2 API Workflows in Studio Web 21.3 HTTP Requests: Web APIs, the Orchestrator API & Connector Requests 21.4 Connector Builder: Custom Integration Service Connectors 21.5 Integration Service Event Triggers: Connected and Disconnected 21.6 GenAI Activities: Generative AI Inside Workflows
22 Chapter 22: Data Service, Context Grounding & Coded Workflows
22.1 Data Fabric (Data Service) Entities: Modeling Business Data 22.2 Data Fabric Activities and the Platform Connector 22.3 Context Grounding: Retrieval-Augmented Generation with Company Data 22.4 Coded Automations: Structure, Arguments & Invoking Workflows 22.5 Coded Automation Services: Orchestrator, UI Automation, Microsoft 365 & Custom Services
23 Chapter 23: Integrated Scenario Practice
23.1 Integrated Scenario Practice: Designing an End-to-End Solution
16.1 UiPath Test Suite Overview, Test Cases & Given-When-Then Structure
Key Takeaways Explain This Topic AI
Studio designs test cases, Orchestrator and Test Manager organize and run test sets, and robots with Testing runtimes execute them; Orchestrator's testing module is being deprecated in favor of Test Manager.
Unit tests check isolated workflows with mocked dependencies, integration tests check handoffs between workflows, and end-to-end tests run the whole process against test systems.
Create Test Case on a workflow generates a Given-When-Then test case that invokes the workflow in When.
Given sets up preconditions, When runs the workflow under test, and Then holds verification activities.
Test arguments and folder-scoped test assets keep environment values out of test logic.
Last updated: September 2026
16.1 UiPath Test Suite Overview, Test Cases & Given-When-Then Structure
Core Concept: UiPath Test Suite is an enterprise-grade testing and quality engineering platform designed to validate both software automations (RPA workflows) and underlying enterprise applications (web, desktop, SAP, mobile, and APIs). Unlike conventional software testing where the subject under test (SUT) is a static web application, RPA testing validates the autonomous software robot, its dynamic handling of underlying target systems, and its transactional resiliency. Test cases in UiPath Studio are built upon Behavior-Driven Development (BDD) patterns, orchestrating test logic into clear Given-When-Then execution phases.
In high-throughput enterprise automation, deploying untested or manually validated RPA processes into production introduces catastrophic risks. A silent change in an ERP web table selector, an unexpected null field in an incoming transaction payload, or an unhandled boundary condition can crash unattended robots, corrupt transactional queues, and halt critical business operations. UiPath Test Suite bridges the gap between software development, RPA operations, and traditional QA by providing one platform for test design, execution, and management.
1. Architecture of the UiPath Test Suite Ecosystem
UiPath's testing capabilities span several products, each covering a stage of the test lifecycle: Studio (design test cases) --publish--> Orchestrator / Test Manager (test sets)
- ^ |
- | requirements, results v run
- Test Manager (requirements, reports) <-- Robots with Testing runtimes
- |
- v integration
- Jira / Azure DevOps
- The Components
Component Role in testing
Studio Test design: test cases (Given-When-Then), the Test Explorer panel, activity coverage, data-driven test data, and mock testing
Orchestrator Test execution: test sets, schedules, and test results in folders. UiPath has announced the deprecation of Orchestrator's testing module and provides guidance for migrating test artifacts to Test Manager
Test Manager Test management: requirements, manual and automated test cases, test sets and executions, reports such as requirement coverage, and integrations with tools such as Jira and Azure DevOps
- Robots with Testing runtimes Run automated test cases, including unattended and serverless execution
- 2. The RPA Testing Taxonomy: Unit, Integration, and System Tests
Effective RPA quality assurance requires a multi-tiered testing strategy. Attempting to validate an entire enterprise automation only through full end-to-end runs creates brittle, slow, and expensive test cycles. UiPath defines three primary testing tiers:
Dimension Unit Testing Integration Testing System / End-to-End (E2E) Testing
Scope Single, isolated sub-workflow ( .xaml ) or custom activity. Interaction between multiple linked workflows or system interfaces. Full business process from initiation trigger to final downstream output.
Subject Under Test (SUT) Modular components (e.g., CalculateTax.xaml , ExtractTable.xaml ). Workflow chains (e.g., InitAllSettings feeding InitAllApplications ). Complete REFramework process ( Main.xaml ) running against full infrastructure.
External Dependencies Fully isolated; external APIs, DBs, and UI elements are mocked. Partially mocked; internal queues and staging databases are utilized. Unmocked; connected to real staging/test enterprise systems (SAP, CRM, portals).
Execution Speed Extremely fast (milliseconds to several seconds). Moderate (several seconds to 1–2 minutes). Long-running (several minutes to hours).
Primary Objective Validate internal business logic, edge conditions, and data transformations. Validate contract interfaces, argument passing, and queue handoffs. Validate operational SLAs, system resiliency, security, and global exception paths.
1. Unit Testing in RPA
Unit testing validates the smallest testable units of an RPA project—individual sub-workflows. In a well-architected project following modular design, tasks such as string parsing, tax calculation, PDF regex extraction, and JSON payload formatting reside in isolated .xaml files. Unit tests isolate these files from external systems using Mock Activities to supply predetermined inputs and verify expected outputs without touching live databases or UI controls.
2. Integration Testing in RPA
Integration testing verifies that modular workflows collaborate correctly. In the Robotic Enterprise Framework (REFramework), an integration test might evaluate whether GetTransactionData.xaml properly extracts an item from an Orchestrator Queue and passes the strongly typed SpecificContent dictionary to Process.xaml . It ensures data contract fidelity, error propagation, and retry dynamics between interrelated components.
3. System and End-to-End (E2E) Testing in RPA
System testing executes the entire end-to-end automation in an environment that mirrors production (Staging/UAT). It validates that the robot successfully logs into enterprise target applications (e.g., SAP GUI, Salesforce, internal web portals), navigates real UI hierarchies, extracts data, writes records to transactional systems, handles operational exceptions gracefully, and updates Orchestrator queue statuses within acceptable performance thresholds.
3. Converting Standard Workflows to Test Cases
In UiPath Studio, standard automation workflows and test cases are both saved as .xaml files, but they serve fundamentally distinct operational purposes within the project lifecycle. +-------------------------------------------------------------------------+
- | STANDARD WORKFLOW VS. TEST CASE XAML |
- | |
- | Standard Workflow (.xaml) Test Case (.xaml) |
- | - Executed by unattended robots - Executed by testing robots |
- | - Standard process logic - BDD structure (Given/When/Then)
- | - Packaged for Process deployment - Packaged for Test execution |
- | - Ignored by Test Explorer - Discovered by Test Explorer |
- | - No assertion activities required - Contains Verification nodes |
- +-------------------------------------------------------------------------+
- Conversion Mechanics in Studio
Developers can easily transform existing modular workflows into formal test cases without re-authoring workflow logic:
Open the Project panel in UiPath Studio.
Locate and right-click the target workflow file (for example, Workflows\CalculateInvoiceDiscount.xaml ).
Select Create Test Case from the context menu.
In the Create Test Case window, give the test case a name and location, and optionally select Mock workflow under test to create a mock copy of the workflow.
Studio generates a new .xaml test case with the Given-When-Then structure.
The newly created test case automatically appears in the Test Explorer panel, ready for execution, debugging, or parameterization.
Note
When a test case is created from an existing workflow, Studio automatically places an Invoke Workflow File activity inside the When container, pre-mapping all In , Out , and InOut arguments declared in the underlying workflow to local test variables.
4. The BDD Paradigm: Given-When-Then Execution Architecture
UiPath test cases natively implement the principles of Behavior-Driven Development (BDD) . BDD promotes clarity, collaboration, and maintainability by structuring automated tests into three distinct temporal scopes: Given , When , and Then . +-----------------------------------------------------------------------------+
- | BDD TEST CASE ARCHITECTURE |
- | |
- | +---------------------------------------------------------------------+ |
- | | GIVEN (Setup & Preconditions) | |
- | | - Initialize test variables and configuration dictionaries | |
- | | - Stage test data (e.g., instantiate DataTable, load test records) | |
- | | - Configure mock data returns and launch test application state | |
- | +---------------------------------------------------------------------+ |
- | │ |
- | ▼ |
- | +---------------------------------------------------------------------+ |
- | | WHEN (Action & Execution) | |
- | | - Invoke the workflow under test via Invoke Workflow File | |
- | | - Pass input arguments and capture output arguments | |
- | | - Measure execution duration and trap uncaught exceptions | |
- | +---------------------------------------------------------------------+ |
- | │ |
- | ▼ |
- | +---------------------------------------------------------------------+ |
- | | THEN (Assertions & Verification) | |
- | | - Verify output argument values via Verify Expression activities | |
- | | - Inspect UI state changes via Verify Control Attribute | |
- | | - Confirm database mutations and assert business postconditions | |
- | +---------------------------------------------------------------------+ |
- | │ |
- | ▼ (Optional) |
- | +---------------------------------------------------------------------+ |
- | | TEARDOWN / CLEANUP | |
- | | - Close application sessions, delete temporary files, restore state | |
- | +---------------------------------------------------------------------+ |
- +-----------------------------------------------------------------------------+
- Container Responsibilities in Detail
- 1. The Given Container (Preconditions & Staging)
Purpose: Prepares the execution environment so that the subject under test can run in a controlled, deterministic state.
Typical Activities:
Initializing configuration dictionaries ( InitAllSettings or hardcoded test dictionaries).
Creating mock input variables (e.g., assigning testInvoiceAmount = 1500.00 , testCustomerTier = "Gold" ).
Seeding databases with known test records or clearing target folders.
Navigating the browser or desktop application to the specific landing page expected by the workflow.
2. The When Container (Execution)
Purpose: Executes the specific business logic or sub-workflow being evaluated.
Typical Activities:
An Invoke Workflow File activity calling the target workflow.
Binding the input arguments from the Given stage ( in_Amount = testInvoiceAmount ).
Storing the output arguments into local test variables ( out_FinalDiscount = actualDiscount ).
Design Rule: The When container should remain minimal and focused exclusively on invoking the action under test. Avoid placing setup logic or validation assertions inside When .
3. The Then Container (Assertions & Verification)
Purpose: Validates that the execution produced the expected business outcome and postconditions.
Typical Activities:
Executing specialized verification activities from the UiPath.Testing.Activities package.
Verify Expression with Operator (e.g., comparing actualDiscount with expectedDiscount ).
Verify Control Attribute (e.g., verifying that a web banner displays "Order Successfully Submitted").
Querying a test database to verify that a record was updated from Pending to Processed .
4. The Teardown Phase
While not represented as a default top-level visual container in standard templates, enterprise test cases often wrap execution in a TryCatch or append a sequence at the end of Then to perform teardown. Teardown logic closes opened browser tabs, terminates test desktop processes via Kill Process , and deletes temporary test artifacts, preventing test state leakage across iterations.
5. Managing Test Parameters and Test Assets
In robust test engineering, hardcoding environmental values (such as test server URLs, test tenant IDs, or mock credentials) directly inside test cases creates severe maintenance overhead. UiPath provides two primary mechanisms to externalize test configurations: Test Parameters and Test Assets .
Test Parameters (Test Arguments)
Test cases declare arguments just like standard workflows. When a test case declares arguments with the In direction (e.g., in_TestEnvironment , in_TargetVendorCode ), Studio treats these as Test Parameters .
When executing locally from the Test Explorer , developers can supply custom parameter values in the execution dialog.
When published to Orchestrator and Test Manager, these parameters can be bound to external datasets, allowing automated test pipelines to override inputs dynamically without recompiling the project.
Test Assets in Orchestrator
Production robots and testing robots should never share the same database connections or live service credentials.
By leveraging modern Orchestrator folders (e.g., Testing_Folder vs. Production_Folder ), automation architects create Test Assets with identical asset names as production (e.g., SAP_Credentials , Invoicing_DB_ConnectionString ), but whose underlying values point to sandbox databases, test SAP instances, and mock payment services.
When the test case invokes standard activities like Get Credential or Get Asset, Orchestrator automatically resolves the asset in the testing robot's assigned folder, isolating test operations from production data. ' Visual Basic .NET snippet illustrating a parameterized BDD test case assertion:
' GIVEN:
- Dim testTaxRate As Double = 0.0825
- Dim testSubTotal As Decimal = 100.00D
- Dim expectedTotal As Decimal = 108.25D
- Dim actualTotal As Decimal
' WHEN:
' Invoke CalculateInvoiceTax.xaml(in_SubTotal:=testSubTotal, in_TaxRate:=testTaxRate, out_Total:=actualTotal)
' THEN:
' Verify Expression with Operator activity: