Probar tu actividad

Después de implementar la nueva actividad, es importante probar que funciona como se espera. Puedes probar tu actividad de una de las siguientes maneras.

Pruebas unitarias

La forma más fácil y rápida de probar el código de actividad es escribir pruebas unitarias que aíslen el código de actividad y prueben escenarios individuales.

Por ejemplo:

[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);
}[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);
}

En este ejemplo, simplemente creamos una nueva instancia de la clase Calculator y llamamos a la función ExecuteInternal . No hay nada específico relacionado con las actividades en este contexto y se aplican los principios básicos de las pruebas unitarias.

Para ver un ejemplo, ve a la actividad Calculadora de muestra en GitHub.

Pruebas de flujo de trabajo

Las pruebas de flujo de trabajo son un tipo de pruebas unitarias que se basan en la clase WorkflowInvoker para colocar la actividad dentro de un flujo de trabajo y ejecutarla como lo haría UiPath Robot.

Veamos este ejemplo:

[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);
}[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);
}

De forma similar a la prueba unitaria, creamos una nueva instancia de la actividad, pero en lugar de llamar a los métodos directamente en la instancia, colocamos la actividad dentro de un WorkflowInvoker y la ejecutamos como parte de un flujo de trabajo. El flujo de trabajo llamará finalmente a la función Execute en la clase Calculator . Ten en cuenta que esta función está protegida y no podemos invocarla directamente, lo cual es un beneficio indirecto de utilizar este enfoque.

Este enfoque suele utilizarse cuando la actividad depende del resultado de otras actividades. En este caso, crearíamos un flujo de trabajo con múltiples actividades y dejaríamos que WorkflowInvoker lo ejecute.

UiPath Studio adjuntar al proceso

A veces, es necesario probar el código de actividad dentro del ejecutor de UiPath.Robot. Para lograrlo, podemos utilizar una de dos opciones.

Opción 1: System.Diagnostics.Debugger.Launch()

Añade Debugger.Launch() donde quieras que el punto de interrupción llegue a tu código.
Crea el nuevo paquete y actualiza la versión en tu proyecto en UiPath.Studio, y luego selecciona Ejecutar.
El depurador JIT te pide que elijas una instancia de Visual Studio para la depuración.
Después de seleccionar la instancia, el JIT detendrá la ejecución en la línea donde se añadió Debugger.Launch() y desde allí puede comenzar el proceso de depuración normal.

Opción 2: Adjuntar al proceso en Visual Studio

Otra opción es retrasar la ejecución y luego adjuntar Visual Studio al proceso ejecutor. Aunque este método requiere más gastos generales, permite depurar el código de actividad sin modificaciones.

Para retrasar la ejecución, añade la actividad Retraso o, en un proyecto de Windows, la actividad Cuadro de mensaje .
Selecciona Ejecutar y, a continuación, ve a Visual Studio y selecciona Depurar > Adjuntar al proceso.
Filtra la lista de procesos por UiPath.Executor, selecciona todos los procesos y luego haz clic en Adjuntar.