SDK
Neuestes
False
Bannerhintergrundbild
Entwickleranleitung
Letzte Aktualisierung 23. März 2024

Ihre Aktivität wird getestet

Nach der Implementierung der neuen Aktivität ist es wichtig, zu testen, ob sie wie erwartet funktioniert. Sie können Ihre Aktivität auf eine der folgenden Arten testen.

Komponententests

Die einfachste und schnellste Möglichkeit, den Aktivitätscode zu testen, besteht darin, Einheiten-Tests zu schreiben, die den Aktivitätscode isolieren und einzelne Szenarien testen.

Zum Beispiel:

[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);
}
In diesem Beispiel erstellen wir einfach eine neue Instanz der Calculator -Klasse und rufen die Funktion ExecuteInternal auf. Es gibt nichts Spezifisches im Zusammenhang mit Aktivitäten in diesem Kontext und es gelten die grundlegenden Grundsätze des Einheitentests.

Ein Beispiel finden Sie in der Aktivität „Rechner “ in GitHub.

Workflow-Tests

Workflow-Tests sind eine Art von Einheiten-Tests, die auf der Klasse WorkflowInvoker basieren, um die Aktivität in einem Workflow zu platzieren und sie so auszuführen, wie sie von UiPath Robot ausgeführt werden würde.

Sehen wir uns dieses Beispiel an:

[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);
}
Ähnlich wie beim Einheiten-Test erstellen wir eine neue Instanz der Aktivität, aber anstatt die Methoden direkt auf der Instanz aufzurufen, platzieren wir die Aktivität in einem WorkflowInvoker und führen sie als Teil eines Workflows aus. Der Workflow ruft schließlich die Funktion Execute für die Klasse Calculator auf. Beachten Sie, dass diese Funktion geschützt ist und wir sie nicht direkt aufrufen können, was ein indirekter Vorteil dieses Ansatzes ist.
Dieser Ansatz wird normalerweise verwendet, wenn die Aktivität vom Ergebnis anderer Aktivitäten abhängig ist. In diesem Fall würden wir einen Workflow mit mehreren Aktivitäten erstellen und den WorkflowInvoker ausführen lassen.

UiPath Studio an Prozess anhängen

Manchmal ist es erforderlich, den Aktivitätscode innerhalb des UiPath.Robot-Executors zu testen. Um dies zu erreichen, können wir eine von zwei Optionen verwenden.

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

  1. Fügen Sie Debugger.Launch() an der Stelle hinzu, an der der Haltepunkt Ihren Code treffen soll.
  2. Erstellen Sie das neue Paket, und aktualisieren Sie die Version in Ihrem Projekt in UiPath.Studio, und wählen Sie dann Ausführen aus.
  3. Der JIT-Debugger fordert Sie auf, eine Visual Studio-Instanz auszuwählen, die für das Debuggen verwendet werden soll.



  4. Nachdem Sie die Instanz ausgewählt haben, stoppt das JIT die Ausführung an der Zeile, in der Debugger.Launch() hinzugefügt wurde, und ab dort kann der normale Debugprozess beginnen.


Option 2: An Prozess in Visual Studio anhängen

Eine andere Option besteht darin, die Ausführung zu verzögern und dann Visual Studio an den Executor-Prozess anzuhängen. Diese Methode erfordert zwar mehr Aufwand, ermöglicht aber das Debuggen des Aktivitätscodes ohne Änderungen.

  1. Um die Ausführung zu verzögern, fügen Sie die Aktivität Verzögerung ( Delay ) oder, in einem Windows-Projekt, die Aktivität Meldungsfeld ( Message Box ) hinzu.



  2. Wählen Sie Ausführen aus, wechseln Sie dann zu Visual Studio und wählen Sie Debuggen > An Prozess anhängen aus.



  3. Filtern Sie die Prozessliste nach UiPath.Executor, wählen Sie alle Prozesse aus und klicken Sie dann auf Anhängen.


Nachdem die Verzögerung abgelaufen ist, wird die Prozessausführung an dem Haltepunkt unterbrochen, den Sie in Ihrem Code hinzugefügt haben.

War diese Seite hilfreich?

Hilfe erhalten
RPA lernen – Automatisierungskurse
UiPath Community-Forum
UiPath Logo weiß
Vertrauen und Sicherheit
© 2005-2024 UiPath. All rights reserved.