sdk
latest
false
Important :
Veuillez noter que ce contenu a été localisé en partie à l’aide de la traduction automatique. La localisation du contenu nouvellement publié peut prendre 1 à 2 semaines avant d’être disponible.
UiPath logo, featuring letters U and I in white

Guide du développeur

Dernière mise à jour 30 oct. 2025

Tester votre activité

After implementing the new activity, test that it works as expected. You can test your activity using one of these methods:

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);
}
The previous code snippet example creates a new instance of the Calculator class and calls 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.

Tests de workflow

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:
[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);
}
The previous code snippet create a new instance of the activity, but instead of calling the methods directly on the instance, it places the activity inside a WorkflowInvoker and runs it as part of a workflow. The workflow eventually calls the Execute function on the Calculator class. Notice that this function is protected and you cannot 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, you need to create an workflow with multiple activities and let WorkflowInvoker execute it.

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()

  1. Ajoutez Debugger.Launch() où vous souhaitez que le point d'arrêt atteigne votre code.
  2. Créez le nouveau package et mettez à jour la version de votre projet dans UiPath.Studio, puis sélectionnez Exécuter(Run).
  3. Le débogueur JIT vous invite à choisir une instance de Visual Studio à utiliser pour le débogage.



  4. 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.

  1. Pour différer l'exécution, ajoutez l'activité Délai ou, dans un projet Windows, l'activité Zone de message .



  2. Sélectionnez Exécuter(Run), puis accédez à Visual Studio et sélectionnez Déboguer (Debug) > Joindre au processus (Attach to process).



  3. Filtrez la liste des processus par UiPath.Executor, sélectionnez tous les processus, puis cliquez sur Joindre ( Attach).


Une fois le délai écoulé, l'exécution du processus est interrompue au point d'arrêt que vous avez ajouté dans votre code.

Cette page vous a-t-elle été utile ?

Obtenez l'aide dont vous avez besoin
Formation RPA - Cours d'automatisation
Forum de la communauté UiPath
Uipath Logo
Confiance et sécurité
© 2005-2025 UiPath Tous droits réservés.