16.2 Data-Driven Testing, Test Verification Activities & Mock Activities

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:

1. Excel or CSV files: each column maps to an argument of the test case and each row is one data variation.
2. Data Service (Data Fabric) entities: records of an entity supply the variations.
3. 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

1. Create a test case with test data, or open the context menu of an existing test case and add or update test data.
2. Choose the Source (file, Data Service entity, or Test Data Queue) and select the data.
3. 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.
4. 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

---

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:

1. 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.
2. 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.
3. 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