Study guide
4.3 Testing a REFramework Project With and Without Orchestrator Queues
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
4.3 Testing a REFramework Project With and Without Orchestrator Queues
Key Takeaways Explain This Topic AI
The template's Tests folder includes test cases such as GeneralTestCase.xaml, GetTransactionDataTestCase.xaml, and ProcessTestCase.xaml, which use the Given, When, Then structure and run from Test Explorer.
The standard ProcessTestCase retrieves a real queue item, so running it changes that item's status; use a separate test queue.
Without a queue, build a QueueItem in memory with SpecificContent, or convert test data queue values into SpecificContent before invoking Process.xaml.
Assert both paths: valid data succeeds and invalid data raises a BusinessRuleException.
Last updated: September 2026
4.3 Testing a REFramework Project With and Without Orchestrator Queues
Core Concept: The exam description asks you to test a REFramework project with and without Orchestrator queues . The template ships with a Tests folder of ready-made test cases for its framework workflows. You can run them from Test Explorer , and you can adapt them so a transaction does not depend on a live queue item.
The Tests Folder in the Template
Recent versions of the template include test cases that exercise the framework in isolation, for example:
- Test case What it checks
- GeneralTestCase.xaml A general pattern for testing a single workflow with the framework's settings loaded
GetTransactionDataTestCase.xaml Loads the settings, sets a TransactionNumber, runs GetTransactionData.xaml , and verifies that an item was retrieved; with a queue, the retrieved item moves to In Progress , so the queue name must be configured
ProcessTestCase.xaml Runs Process.xaml for one transaction item and verifies the outcome
Similar test cases cover the initialization workflows. Each follows the Given, When, Then structure of UiPath test cases. Given loads Config by invoking InitAllSettings.xaml , When invokes the workflow under test, and Then asserts the result with Verify activities.
You run them from the Test Explorer panel or the Run Test options in Studio. Results show pass or fail per test case, and activity coverage shows which parts of the workflows the tests reached.
Testing With a Queue
With a queue-based performer, the most realistic test uses a test queue in a development folder:
Create a queue in a dev or test folder with the same name the Config file points to (or point OrchestratorQueueName and OrchestratorQueueFolder at the test queue).
Add a few known items: a valid invoice, one that should raise a business exception, and one that forces a system error, such as a wrong URL.
Run GetTransactionDataTestCase.xaml and ProcessTestCase.xaml , then the full project in debug mode.
Check the Transactions page: you should see Successful, Failed (Business), and Failed (Application) with the expected Retried copies.
The trap noted in the template's documentation is that the standard ProcessTestCase retrieves a real queue item . Running it consumes that item, which moves to In Progress. A test run can therefore change the state of a shared queue, which is one reason to keep test queues separate from production.
Testing Without a Queue
You often want to test Process.xaml without any queue. Common approaches:
1. Build the QueueItem yourself
Process.xaml usually reads in_TransactionItem.SpecificContent("Key") . A test can create the item in memory: transactionItem = New UiPath.Core.QueueItem With {
- .SpecificContent = New Dictionary(Of String, Object) From {
- {"InvoiceNo", "INV-1001"}, {"Amount", 250.0}
- }
- }
Then invoke Process.xaml with that item and assert the outputs. No Orchestrator call is made, so nothing changes status.
2. Test data queues
Orchestrator's test data queues are managed separately from transaction queues and are read with activities such as Get Test Data Queue Item , which can also mark an item as consumed. The activity returns the item's data as a dictionary rather than a QueueItem , so convert the dictionary into SpecificContent , as in approach 1, before invoking Process.xaml.
3. Data-driven test cases
Import a test data file (Excel or JSON) as test case arguments so one test case runs once per variation: valid data, missing fields, and boundary values. Each variation builds its own item and checks for either success or a BusinessRuleException .
4. Switch the project to non-queue data
When the project itself is adapted to tabular data, a test can pass a small DataTable as io_TransactionData , run GetTransactionData.xaml for TransactionNumber 1, 2, and 3, and assert that the fourth call returns Nothing .
What to Assert
- Test Assertion
- Configuration Config.ContainsKey("OrchestratorQueueName") and required assets are present
- Get Transaction Data An item is returned while data remains; Nothing is returned at the end
Business rule Invalid data throws BusinessRuleException , which you check by catching it or with a verification step
- System failure Applications close and the retry counter changes as expected
- Full run Queue statuses or the output file match the expected outcome for each record
Mocking helps when Process.xaml calls something you must not hit in a test, such as a payment API. Mock testing in Studio creates a mock copy of the workflow in which the risky activity is replaced, so the real workflow stays unchanged.
A Short Testing Checklist
Point OrchestratorQueueName and OrchestratorQueueFolder at a test queue before running any queue-based test case.
Keep one test item per outcome: success, business exception, and system exception.
Run the framework test cases first, then the full project in debug mode.
Confirm the log fields: each transaction's logs should show your business ID in logF_TransactionID .
Reset or delete test items afterwards so the next run starts from known data.