Tester votre activité

Après avoir implémenté la nouvelle activité, il est important de tester qu'elle fonctionne comme prévu. Vous pouvez tester votre activité en suivant une de ces méthodes.

Tests unitaires

Le moyen le plus simple et le plus rapide de tester le code d'activité consiste à écrire des tests unitaires qui isolent le code d'activité et testent des scénarios individuels.

Par exemple :

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

Dans cet exemple, nous créons simplement une nouvelle instance de la classe Calculator et appelons la fonction ExecuteInternal . Il n'y a rien de spécifique lié aux activités dans ce contexte et les principes de test unitaire de base s'appliquent.

Pour voir un exemple, accédez à l' exemple d'activité Calculatrice (Calculator) dans GitHub.

Tests de workflow

Les tests de workflow sont un type de tests unitaires qui reposent sur la classe WorkflowInvoker pour placer l'activité dans un workflow et l'exécuter comme si elle était exécutée par le robot UiPath.

Regardons ensemble :

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

Comme pour le test unitaire, nous créons une nouvelle instance de l'activité, mais au lieu d'appeler les méthodes directement depuis l'instance, nous plaçons l'activité dans un WorkflowInvoker et l'exécutons dans le cadre d'un workflow. Le workflow appellera éventuellement la fonction Execute sur la classe Calculator . Notez que cette fonction est protégée et que nous n’avons pas pu l’invoquer directement, ce qui est un avantage indirect de l'utilisation de cette approche.

Cette approche est généralement utilisée lorsque l'activité dépend du résultat d'autres activités. Dans ce cas, nous créons un workflow avec plusieurs activités et laisons le WorkflowInvoker l’exécuter.

Joindre UiPath Studio au processus

Parfois, il est nécessaire de tester le code d'activité à l'intérieur de l'exécuteur UiPath.Robot. Pour ce faire, nous pouvons utiliser l'une des deux options suivantes.

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

Ajoutez Debugger.Launch() où vous souhaitez que le point d'arrêt atteigne votre code.
Créez le nouveau package et mettez à jour la version de votre projet dans UiPath.Studio, puis sélectionnez Exécuter(Run).
Le débogueur JIT vous invite à choisir une instance de Visual Studio à utiliser pour le débogage.
Après avoir sélectionné l'instance, le JIT arrêtera l'exécution à la ligne où Debugger.Launch() a été ajouté, et à partir de là, le processus de débogage normal pourra commencer.

Option 2 : attacher au processus dans Visual Studio

Une autre option consiste à retarder l'exécution, puis à attacher Visual Studio au processus exécuteur. Bien que cette méthode nécessite plus de surcharge, elle permet de déboguer le code d'activité sans modifications.

Pour différer l'exécution, ajoutez l'activité Délai ou, dans un projet Windows, l'activité Zone de message .
Sélectionnez Exécuter(Run), puis accédez à Visual Studio et sélectionnez Déboguer (Debug) > Joindre au processus (Attach to process).
Filtrez la liste des processus par UiPath.Executor, sélectionnez tous les processus, puis cliquez sur Joindre ( Attach).