Testing your activity

After implementing the new activity, it’s important to test that it works as expected. You can test your activity in one of the following ways.

Unit tests

The easiest and fastest way to test the activity code is to write unit tests that isolate the activity code and test individual scenarios.

For example:

[Theory]
[InlineData(1, Operation.Add, 1, 2)]
[InlineData(3, Operation.Subtract, 2, 1)]
[InlineData(3, Operation.Multiply, 2, 6)]
[InlineData(6, Operation.Divide, 2, 3)]
public void Calculator_ReturnsAsExpected(int firstNumber, Operation operation, int secondNumber, int expectedResult)
{
    var calculator = new Calculator()
    {
        SelectedOperation = operation
    };

    var result = calculator.ExecuteInternal(firstNumber, secondNumber);

    Assert.Equal(expectedResult, result);
}

In this example, we simply create a new instance of the Calculator class and call the ExecuteInternal function. There is nothing specific related to activities in this context and basic unit testing principles apply.

To see an example, go to the sample Calculator activity in GitHub.

Workflow tests

Workflow tests are a type of unit tests that rely on the WorkflowInvoker class to place the activity inside a workflow and run it as it would be run by UiPath Robot.

Let’s look at this example:

[Fact]
public void Divide_ReturnsAsExpected()
{
    var activity = new Calculator()
    {
        FirstNumber = 4,
        SecondNumber = 2,
        SelectedOperation = Operation.Divide
    };

    var runner = new WorkflowInvoker(activity);
    runner.Extensions.Add(() => workflowRuntimeMock.Object);

    var result = runner.Invoke(TimeSpan.FromSeconds(1)); //the runner will return a dictionary with the values of the OutArguments

    //verify that the result is as expected
    Assert.Equal(2, result["Result"]);

    //verify that we logged a message
    workflowRuntimeMock.Verify(x => x.LogMessage(It.IsAny<LogMessage>()), Times.Once);
}

Similarly to the unit test, we create a new instance of the activity, but instead of calling the methods directly on the instance, we place the activity inside a WorkflowInvoker and run it as part of a workflow. The workflow will eventually call the Execute function on the Calculator class. Notice that this function is protected and we could not invoke it directly, which is an indirect benefit of using this approach.

This approach is usually used when the activity is dependent on the result of other activities. In this case, we would create an workflow with multiple activities and let the WorkflowInvoker execute it.

UiPath Studio attach to process

Sometimes, it is necessary to test the activity code inside the UiPath.Robot executor. To achieve this, we can use one of two options.

Option 1: System.Diagnostics.Debugger.Launch()

1. Add Debugger.Launch() where you want the breakpoint to hit your code.
2. Build the new package and update the version in your project in UiPath.Studio, and then select Run.

3. The JIT Debugger prompts you to choose a Visual Studio instance to use for debugging.

   
   

   

   
   
4. After you select the instance, the JIT will stop the execution at the line where the Debugger.Launch() was added and from there the normal debug process can begin.
   
   

   

   
   

Option 2: Attach to process in Visual Studio

Another option is to delay the execution and then attach Visual Studio to the executor process. While this method requires more overhead, it allows debugging the activity code without modifications.

1. To delay execution, add the Delay activity or, in a Windows project, the Message Box activity.

   
   

   

   
   

2. Select Run, and then go to Visual Studio and select Debug > Attach to process.

   
   

   

   
   
3. Filter the process list by UiPath.Executor, select all processes, and then click Attach.
   
   

   

   
   

After the delay passes, the process execution is interrupted at the breakpoint you added in your code.