4.3 Testing a REFramework Project With and Without Orchestrator Queues

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:

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:

1. 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).
2. 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.
3. Run GetTransactionDataTestCase.xaml and ProcessTestCase.xaml, then the full project in debug mode.
4. 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

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

1. Point OrchestratorQueueName and OrchestratorQueueFolder at a test queue before running any queue-based test case.
2. Keep one test item per outcome: success, business exception, and system exception.
3. Run the framework test cases first, then the full project in debug mode.
4. Confirm the log fields: each transaction's logs should show your business ID in logF_TransactionID.
5. Reset or delete test items afterwards so the next run starts from known data.