Study guide
16.2 Data-Driven Testing, Test Verification Activities & Mock Activities
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.2 Data-Driven Testing, Test Verification Activities & Mock Activities
Key Takeaways Explain This Topic AI
Data-driven test cases take variations from Excel or CSV files, Data Service entities, or Test Data Queues.
Verification activities include Verify Expression, Verify Expression With Operator (Equality, Inequality, GreaterThan, GreaterThanOrEqual, LessThan, LessThanOrEqual), Verify Range, and Verify Control Attribute.
ContinueOnFailure defaults to True, so a failed verification is recorded and the test continues unless you set it to False.
Mock workflow under test creates workflowName_mock under Project > Mocks, where Surround with Mock replaces activities without touching the original workflow.
Only mocked activities are editable in mock files, activity coverage ignores mock activities, and mocks are not available in Test Automation projects.
Last updated: September 2026
16.2 Data-Driven Testing, Test Verification Activities & Mock Activities
Core Concept: Enterprise automation testing requires validating business logic across hundreds of boundary conditions, edge cases, and unexpected permutations without duplicating workflow code. Data-Driven Testing (DDT) enables a single parameterized test case to iterate dynamically across external datasets. To evaluate outcomes, UiPath provides specialized Test Verification activities that capture granular diagnostics and screenshots upon failure. Furthermore, to isolate automated tests from destructive or volatile external systems (such as financial clearinghouses, ERP systems, or SMS gateways), the Mock Activity engine allows developers to substitute simulated responses without modifying production workflows.
When testing software robots, testing only happy-path scenarios is a recipe for production outages. An invoice processing robot might handle standard domestic vendors flawlessly, but crash when encountering a foreign vendor with international tax structures, special currency formats, or missing tax exemption IDs. By coupling Data-Driven Testing with non-intrusive Mocking and rigorous Verification assertions, automation engineers can achieve comprehensive test coverage across complex enterprise scenarios.
1. Data-Driven Testing (DDT) in UiPath Studio
Data-Driven Testing is an automated testing methodology where test input data and expected verification results are stored in external data sources and fed iteratively into a single parameterized test case. +-----------------------------------------------------------------------------+
- | DATA-DRIVEN TESTING ARCHITECTURE |
- | |
- | External Data Source |
- | (Excel / CSV / Data Service entity / Test Data Queue) |
- | +---------+---------------+---------------+----------------+ |
- | | Row No. | in_InvoiceVal | in_VendorTier | expected_Status| |
- | +---------+---------------+---------------+----------------+ |
- | | Row 1 | 500.00 | Tier_A | Approved | |
- | | Row 2 | 15000.00 | Tier_B | ManualReview | |
- | | Row 3 | -50.00 | Tier_A | Rejected | |
- | +---------+---------------+---------------+----------------+ |
- | │ |
- | │ Bound to Test Case Arguments |
- | ▼ |
- | +---------------------------------------------------------------------+ |
- | | Parameterized BDD Test Case (.xaml) | |
- | | | |
- | | Iteration 1: [in_InvoiceVal=500, Tier=A] --> [Pass: Approved] | |
- | | Iteration 2: [in_InvoiceVal=15000, Tier=B] --> [Pass: Review] | |
- | | Iteration 3: [in_InvoiceVal=-50, Tier=A] --> [Pass: Rejected] | |
- | +---------------------------------------------------------------------+ |
- | │ |
- | ▼ |
- | Aggregated Execution Report: 3 Iterations (3 Passed, 0 Failed) |
- +-----------------------------------------------------------------------------+
- Supported Test Data Sources
A data-driven test case gets its variations from one of these sources:
Excel or CSV files: each column maps to an argument of the test case and each row is one data variation.
Data Service (Data Fabric) entities: records of an entity supply the variations.
Test Data Queues in Orchestrator: Studio adds an IDictionary argument named after the queue, and each test iteration pulls one queue item and passes its key-value pairs in that argument.
Setting Up Data-Driven Test Cases in Studio
Create a test case with test data, or open the context menu of an existing test case and add or update test data .
Choose the Source (file, Data Service entity, or Test Data Queue) and select the data.
Studio links the data to the test case's arguments. Each variation appears as its own entry when you run the test case from the Test Explorer .
A failed verification in one variation is reported for that variation; the other variations still run.
2. Test Verification Activities Deep Dive ( UiPath.Testing.Activities )
The UiPath.Testing.Activities package provides specialized activities designed specifically for validating outcomes within the Then container of a BDD test case. Unlike standard programmatic checks (such as an If activity throwing an exception), verification activities integrate natively with the Studio Test Explorer, Orchestrator test reporting, and Test Manager analytics. +-----------------------------------------------------------------------------+
- | TEST VERIFICATION ACTIVITIES SUITE |
- | |
- | 1. Verify Expression |
- | +-------------------------------------------------------------------+ |
- | | Expression: [ actualTax = 8.25 AndAlso status = "Complete" ] | |
- | | Evaluates to: TRUE / FALSE | |
- | +-------------------------------------------------------------------+ |
- | |
- | 2. Verify Expression With Operator |
- | +-------------------------------------------------------------------+ |
- | | First: [ actualTax ] Operator: [ Equality ] Second: [ expected ]| |
- | | Result shows both compared values -> PASSED | |
- | +-------------------------------------------------------------------+ |
- | |
- | 3. Verify Control Attribute |
- | +-------------------------------------------------------------------+ |
- | | Target: [ UI Element - 'lbl_Status' ] | |
- | | Attribute: [ "text" ] Operator: [ Equality ] Value: [ "Success" ]| |
- | +-------------------------------------------------------------------+ |
- +-----------------------------------------------------------------------------+
- 1. Verify Expression
Mechanics: Verifies a single Boolean expression, for example actualCount > 0 AndAlso isAccountActive .
Trade-off: Very flexible, but a failure only tells you the expression was False, not which part failed or which values caused it.
2. Verify Expression With Operator
Mechanics: Compares a FirstExpression and a SecondExpression with an Operator chosen from Equality , Inequality , GreaterThan , GreaterThanOrEqual , LessThan , and LessThanOrEqual .
Advantage: The verification result shows both values that were compared, which makes a failure in a pipeline report much easier to diagnose.
3. Verify Range
Checks whether an expression lies inside or outside a range defined by lower and upper limits.
4. Verify Control Attribute
Combines UI targeting with a verification: it reads an attribute of a UI element, such as its text or enabled state, and compares it with an expected value.
Use Case: Checking that a confirmation label reads "Order submitted" or that a button becomes disabled after a click.
Common Properties of Verification Activities
Property Meaning
ContinueOnFailure Default True : the test continues after a failed verification, which is recorded as failed. Set it to False to stop at the first failure. Inside a Try Catch with ContinueOnFailure True, no error is caught
TakeScreenshotIfFailed / TakeScreenshotIfSucceded Take a screenshot when the verification fails or succeeds
AlternativeVerificationTitle A readable name for the verification shown in Orchestrator instead of the activity name
- OutputMessageFormat Format of the verification message; a global format can be set in Project Settings
- Result Output Boolean with the verification outcome, useful for notifications or custom reports
- 3. Mocking Dependencies in UiPath: The Mock Activity Engine
In enterprise RPA architectures, automated workflows interact with numerous external dependencies: credit card gateways, core banking mainframes, production ERP databases, third-party REST APIs, and outbound email servers. +-----------------------------------------------------------------------------+
- | THE MOCKING ARCHITECTURE |
- | |
- | Production Workflow: ProcessOrder.xaml |
- | [ Read Order ] ---> [ Call Real Stripe API ] ---> [ Update Internal DB ] |
- | │ |
- | │ Create Test Case: Mock workflow under test |
- | ▼ |
- | Mock file: Mocks\ProcessOrder_mock.xaml |
- | [ Read Order ] ---> [ MOCK (Surround with Mock) ] ---> [ Update Internal DB ]
- | | |
- | |-- [Original Activity: Stripe HTTP Request] (Bypassed)
- | |-- [Mocked Activity: Assign out_Token = "tok_test"] |
- | +-----------------------------------------------------+|
- +-----------------------------------------------------------------------------+
- The Problem with Live Dependencies
Destructive Actions: Executing a live test might trigger real credit card charges, generate valid purchasing orders, or dispatch live emails to customers.
Environmental Instability: External sandbox environments or third-party web services often experience downtime, rate limiting, or maintenance windows, leading to false-positive test failures.
Data Unpredictability: External systems may lack reliable test fixtures, making deterministic assertions impossible.
The Historical Anti-Pattern: Code Contamination
Before native mocking, developers inserted conditional branches directly into production workflows: ' ANTI-PATTERN: DO NOT DO THIS IN PRODUCTION WORKFLOWS!
- If isTestingMode Then
- out_AuthCode = "MOCK_AUTH_123"
- Else
- ' Call Real Payment Gateway Activity
- out_AuthCode = CallLiveStripeAPI(creditCardNumber)
- End If
This anti-pattern contaminates production code, increases workflow complexity, introduces security vulnerabilities, and risks deploying test switches into production.
Mock Testing in Studio
Studio's mock testing replaces selected activities, or even whole invoked workflows, with lightweight stand-ins during a test run, without editing the original workflow:
Create the mock file. In the Create Test Case window, select Mock workflow under test . Studio creates a copy named workflowName_mock under Project > Mocks , mirroring the original path. For example, Tests\testFolder01\testCase07.xaml becomes Mocks\Tests\testFolder01\testCase07_mock.xaml . You can also pick an existing mock file from the Mock dropdown.
Surround activities with mocks. In the mock file, right-click an activity and select Surround with Mock . Put the stand-in logic, such as an Assign that sets the expected output, inside the mock. In a Given-When-Then test case, Surround with Mock is available only for activities within When .
Keep mocks in sync. Changes in the source workflow are applied to the mock file when you save the project, and Synchronize Mock syncs mock files or folders on demand. Remove mock activity removes a mock.
Rules to remember:
In a mock file, you can edit only the mocked activities .
A workflow can have several mock files .
Activity coverage counts only the activities of the source workflow, not the mock activities.
Mock testing is not available in Test Automation projects ; it is used in process projects that contain test cases.
The original workflow is never modified, so production logic stays free of test switches.
4. Summary Matrix: Verification Activities & Mocking Patterns
Feature Verify Expression Verify Expression with Operator Verify Control Attribute Mock Activity
Primary Use Complex Boolean logic statements. Comparisons with Equality, Inequality, GreaterThan, and similar operators. UI element state assertions on live screens. Simulating external dependency responses.
Diagnostics Basic True / False outcome. Both compared values in the result. Current attribute vs. expected attribute. The mock's stand-in logic runs instead of the original activity.
Screenshot Supported on failure ( TakeScreenshotIfFailed ). Supported on failure ( TakeScreenshotIfFailed ). Supported on failure ( TakeScreenshotIfFailed ). N/A (Execution activity, not verification).
Production Impact In test case only (No impact). In test case only (No impact). In test case only (No impact). None; the mock file lives in the Mocks folder.