Erstellen von Komponententests aus Standardworkflows in Azure Logic Apps mit Visual Studio Code

Gilt für: Azure Logic Apps (Standard)

Komponententests sind eine wichtige Praxis, die Ihre App oder Lösung während des gesamten Softwareentwicklungslebenszyklus zuverlässig und präzise hält. Komponententests helfen Ihnen bei der effizienten und systematischen Überprüfung der wichtigsten Komponenten in Ihrer Lösung.

Für Workflows der Standardlogik-App können Sie Komponententests mithilfe von Visual Studio Code und der Azure Logic Apps (Standard)-Erweiterung erstellen. Mit dieser Funktion können Sie zuvor ausgeführte Workflowläufe verwenden, um Komponententests zu erstellen und auf Szenarien anzupassen, die von Ihrer Logik-App-Lösung unterstützt werden. Diese Vorgehensweise bietet folgende Vorteile:

Verwenden Sie Workflowausführungen, um Simulierte Daten für bestimmte Vorgänge im Workflow zu generieren.

Mit diesen Daten können Sie Workflows testen, ohne externe Dienste, Systeme oder APIs aufrufen zu müssen. Sie sparen Zeit, und Ihr Workflow bleibt am tatsächlichen Workflowausführungsszenario ausgerichtet.
Verbessern Sie die Workflowqualität, indem Sie potenzielle Probleme identifizieren und beheben, bevor Sie sie in anderen Umgebungen bereitstellen.
Optimieren Sie die Komponententestintegration in Ihren Entwicklungsprozess, und stellen Sie gleichzeitig ein konsistentes und genaues Workflowverhalten sicher.

In diesem Handbuch wird gezeigt, wie Sie eine Komponententestdefinition aus einer Workflowausführung erstellen. Diese Definition simuliert die externen Aufrufe aus jedem Workflowvorgang, ohne die Workflowlogik zu ändern. Wenn Sie einen Komponententest aus einer Workflowausführung erstellen, erhalten Sie ein Komponententestprojekt, das zwei Ordner enthält:

Ein Ordner, der stark typierte Klassen für jeden simulierten Vorgang in Ihrem Workflow enthält.
Ein Ordner für jede Komponententestdefinition, der die folgenden Dateien enthält:
- Eine JSON-Datei, die die generierten simulierten Vorgänge in Ihrem Workflow darstellt.
- Eine C#-Datei, die eine Beispielklasse und Methoden enthält, die Sie zum Einrichten Ihrer eigenen Assertionen verwenden, bestätigen, dass sich der Workflow erwartungsgemäß verhält, und stellen Sie sicher, dass sich der Workflow in Ihrem größeren Azure-Ökosystem zuverlässig und vorhersehbar verhält.

Voraussetzungen

Ein Azure Konto und ein Abonnement. Falls Sie kein Abonnement besitzen, können Sie sich für ein kostenloses Azure-Konto registrieren.
Ein Standardlogik-App-Projekt in Visual Studio Code, das mindestens einen zuvor und lokal ausgeführten Workflow enthält, der zum Erstellen eines Komponententests verwendet werden soll.

Weitere Informationen zum Einrichten und Erstellen von Projekten in Visual Studio Code finden Sie unter Erstellen von Standardlogik-App-Workflows mit Visual Studio Code.

Einschränkungen und bekannte Probleme

Diese Version unterstützt derzeit nur C# zum Erstellen von Komponententests.
Dieses Release unterstützt keine nicht simulierten Aktionen. Stellen Sie sicher, dass alle Aktionen im Ausführungspfad des Workflows simuliert sind.
Diese Version unterstützt nicht die folgenden Aktionstypen:
- Integrationskontoaktionen
- Datenmapperaktionen
- Benutzerdefinierte Codeaktionen
- XML-Aktionen
- Flüssige Aktionen
- EDI-Aktionen zum Codieren und Decodieren

Überprüfen der grundlegenden Konzepte

Die folgende Liste enthält grundlegende, aber wichtige Konzepte zu Komponententests für Standardworkflows:

Test der Logik-App-Komponenten

Eine kontrollierte Workflowausführung, die Simulierte Objekte einjiziert. Diese Objekte stellen entweder den Workflowtrigger oder Aktionen dar, die von externen Diensten oder Systemen abhängen.
Aktion, die simuliert werden kann

Eine Workflowaktion, die von einem externen Dienst oder System abhängt. Sie können diese Aktionen in simulierte Aktionen für die Erstellung und Ausführung von Komponententests konvertieren.

Erstellen eines Komponententests durch eine Workflowausführung

Öffnen Sie in Visual Studio Code Ihr Standard-Logik-App-Projekt.
Wählen Sie auf der Visual Studio Code-Symbolleiste im Menü "Ausführen " die Option "Debuggen starten" aus. (Tastatur: Drücken Sie F5)
Kehren Sie zum Explorer-Fenster zurück. Erweitern Sie im Projekt den Workflowdefinitionsordner.
Öffnen Sie das Kontextmenüworkflow.json , und wählen Sie "Übersicht" aus.
Wählen Sie auf der Übersichtsseite unter "Ausführungsverlauf" den Workflow aus, der zum Erstellen eines Komponententests verwendet werden soll.
Wählen Sie auf der Symbolleiste „Ausführungsverlauf“ die Option Komponententest durch Ausführung erstellen aus.

Geben Sie einen Namen an, der für die Komponententest-, Komponententestklasse und C#-Datei verwendet werden soll.

Im Explorer-Fenster wird unter Dem Ordner "Logik-App-Projekt" ein neuer Projektordner mit dem Namen "Tests " angezeigt. Der Ordner "Tests" enthält die folgenden Ordner und Dateien:

Ordner oder Datei	BESCHREIBUNG
`Tests` \|\| <`logic-app-name`>	In dem `Tests` Ordner erscheint ein <`logic-app-name`> Ordner, wenn Sie einem Logik-App-Projekt Unit-Tests hinzufügen.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`>	Im Ordner <`logic-app-name`> wird ein Ordner <`workflow-name`> angezeigt, wenn Sie Komponententests für einen Workflow hinzufügen.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`> \|\|\|\| `MockOutputs` < `operation-name-outputs` > \|\|\|\|\|.`cs`	Im <`workflow-name`> Ordner befindet sich der `MockOutputs` Ordner mit einer C#-Datei (.cs), die stark typisierte Klassen für jeden Connector-Vorgang im Workflow enthält. Jeder .cs Dateinamen verwendet das folgende Format: < `operation-name` >[`Trigger\\|Action`]`Output.cs` Wenn ein Verbindervorgang dynamische Verträge aufweist, wird für jeden dynamischen Typ eine Klasse angezeigt. Ein dynamischer Typ bezieht sich auf einen Vorgangsparameter mit unterschiedlichen Eingaben und Ausgaben basierend auf dem für diesen Parameter bereitgestellten Wert. Sie können diese Klassen verwenden, um Ihre Unit-Tests zu erweitern und neue Mocks von Grund auf zu erstellen.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`> \|\|\|\| <`unit-test-name`> \|\|\|\|\| <`unit-test-name`>`-mock.json` \|\|\|\|\| <`unit-test-name`>`.cs`	Im <`workflow-name`> Ordner enthält der <`unit-test-name`> Ordner die folgenden Dateien: – Die <`unit-test-name`>`-mock.json` Datei enthält eine JSON-Darstellung der generierten Modelle basierend auf dem Workflowlauf, der den Komponententest erstellt hat. - Die <`unit-test-name`>`.cs` Datei enthält eine C#-Beispielklasse und -Methoden, die die *`-mock.json`** Datei zum Ausführen und Bestätigen von Ergebnissen verwenden. Sie können diese Datei bearbeiten, um Ihren spezifischen Testszenarien zu entsprechen.

Überprüfen sie die Datei *-mock.json

Diese Datei enthält die folgenden Hauptabschnitte:

`triggerMocks` Abschnitt

Der triggerMocks Abschnitt enthält das simulierte Ergebnis des Workflow-Triggers. Dieser Abschnitt ist erforderlich, um die Workflowausführung zu starten, wie im folgenden Beispiel gezeigt:

{
    "triggerMocks": {
        "When_messages_are_available_in_a_queue_(peek-lock)": {
            "name": "When_messages_are_available_in_a_queue_(peek-lock)",
            "status": "Succeeded",
            "outputs": {
                "body": {
                    "contentData": {
                        "messageId": "1234",
                        "status": "new",
                        "contentType": "application/json",
                        "userProperties": {},
                        "scheduledEnqueueTimeUtc": "1/1/0001 12:00:00 AM",
                        "timeToLive": "14.00:00:00",
                        "deliveryCount": 1,
                        "enqueuedSequenceNumber": 0,
                        "enqueuedTimeUtc": "2025-04-07T01:10:09.738Z",
                        "lockedUntilUtc": "2025-04-07T01:11:09.769Z",
                        "lockToken": "78232fa8-03cf-4baf-b1db-3375a64e0ced",
                        "sequenceNumber": 5
                    }
                }
            }
        }
    },
    "actionMocks": {...}
}

`actionMocks` Abschnitt

Für jede simulierte Aktion in einer Workflowausführung enthält der actionMocks Abschnitt eine simulierte Aktion und garantiert die kontrollierte Ausführung des Workflows.

{
    "triggerMocks": {...},
    "actionMocks": {
        "Call_External_API": {
            "name": "Call_External_API",
            "status": "Succeeded",
            "outputs": {
                "statusCode": 200,
                "body": {
                    "status": "Awesome!"
                }
            }
        },
        "CompleteMessage": {
            "name": "CompleteMessage",
            "status": "Succeeded",
            "outputs": {
                "statusCode": "OK",
                "body": {}
            }
        }
    }
}

Überprüfen Sie die *.cs-Datei für die Komponententests

Diese Komponententestklasse stellt ein Framework zum Testen von Standardlogik-App-Workflows bereit, indem Trigger und Aktionen simuliert werden. Mit dieser Klasse können Sie Workflows testen, ohne externe Dienste oder APIs tatsächlich aufzurufen.

Testen der Klassenstruktur

Eine typische Komponententestklasse verwendet die folgende Struktur:

[TestClass]
public class <unit-test-name>
{
    public TestExecutor TestExecutor;

    [TestInitialize]
    public void Setup()
    {
        this.TestExecutor = new TestExecutor("<workflow-name>/testSettings.config");
    }

    // Add test methods here.

    // Add helper methods here.
}

Setup() -Methode

Diese Methode instanziiert die TestExecutor Klasse mithilfe des Pfads zur Konfigurationsdatei für Testeinstellungen. Die Methode wird vor jeder Testausführung ausgeführt und erstellt eine neue Instanz von TestExecutor.

[TestInitialize]
public void Setup()
{
    this.TestExecutor = new TestExecutor("<workflow-name>/testSettings.config");
}

Beispieltestmethoden

Im folgenden Abschnitt werden Beispieltestmethoden beschrieben, die Sie in Ihrer Komponententestklasse verwenden können.

Test statischer Mockdaten

Die folgende Methode zeigt, wie Sie statische Simuliertdaten verwenden, um Ihren Workflow zu testen. In dieser Methode können Sie die folgenden Aufgaben ausführen:

Legen Sie Eigenschaftswerte für Ihre simulierten Aktionen fest.
Führen Sie den Workflow mit den konfigurierten Pseudodaten aus.
Vergewissern Sie sich, dass die Ausführung erfolgreich war.

[TestMethod]
public async Task <workflow-name>_<unit-test-name>_ExecuteWorkflow_SUCCESS_Sample1()
{
    // PREPARE mock: Generate mock action and trigger data.
    var mockData = this.GetTestMockDefinition();
    var sampleActionMock = mockData.ActionMocks["Call_External_API"];
    sampleActionMock.Outputs["your-property-name"] = "your-property-value";

    // ACT: Create the UnitTestExecutor instance. Run the workflow with mock data.
    var testRun = await this.TestExecutor
        .Create()
        .RunWorkflowAsync(testMock: mockData).ConfigureAwait(continueOnCapturedContext: false);

    // ASSERT: Confirm successful workflow execution and that the status is 'Succeeded'.
    Assert.IsNotNull(value: testRun);
    Assert.AreEqual(expected: TestWorkflowStatus.Succeeded, actual: testRun.Status);
}

Dynamischer Test für simulierte Daten

Die folgende Methode zeigt, wie dynamische Mock-Daten mit Rückrufmethoden verwendet werden. Dieser Ansatz bietet Ihnen zwei Optionen, mit denen simulierte Daten dynamisch generiert werden:

Definieren Sie eine separate Rückrufmethode.
Verwenden Sie eine Inline-Lambda-Funktion.

Mit beiden Ansätzen können Sie dynamische Antworten basierend auf dem Ausführungskontext für Komponententests erstellen.

[TestMethod]
public async Task <workflow-name>_<unit-test-name>_ExecuteWorkflow_SUCCESS_Sample2()
{
    // PREPARE: Generate mock action and trigger data.
    var mockData = this.GetTestMockDefinition();
    
    // OPTION 1: Define a callback class.
    mockData.ActionMocks["Call_External_API"] = new CallExternalAPIActionMock(
        name: "Call_External_API", 
        onGetActionMock: CallExternalAPIActionMockOutputCallback);

    // OPTION 2: Define an inline lambda function.
    mockData.ActionMocks["Call_External_API"] = new CallExternalAPIActionMock(
        name: "Call_External_API", 
        onGetActionMock: (testExecutionContext) =>
        {
            return new CallExternalAPIActionMock(
                status: TestWorkflowStatus.Succeeded,
                outputs: new CallExternalAPIActionOutput {

                    // If this account contains a JObject Body, 
                    // set the properties you want here:
                    // Body = "something".ToJObject()

                }
            );
        });
        
    // ACT: Create UnitTestExecutor instance. Run the workflow with mock data.
    var testRun = await this.TestExecutor
        .Create()
        .RunWorkflowAsync(testMock: mockData).ConfigureAwait(continueOnCapturedContext: false);

    // ASSERT: Confirm successful workflow execution and that the status is 'Succeeded'.
    Assert.IsNotNull(value: testRun);
    Assert.AreEqual(expected: TestWorkflowStatus.Succeeded, actual: testRun.Status);
}

Test des Fehlerszenarios

Die folgende Methode zeigt, wie Fehlerbedingungen getestet werden. In dieser Methode können Sie die folgenden Aufgaben ausführen:

Konfigurieren Sie simulierte Aktionen so, dass sie mit bestimmten Fehlercodes und Meldungen fehlschlagen.
Vergewissern Sie sich, dass der Workflow diese Fehlerbedingungen richtig behandelt.

[TestMethod]
public async Task <workflow-name>_<unit-test-name>_ExecuteWorkflow_FAILED_Sample3()
{
    // PREPARE: Generate mock action and trigger data.
    var mockData = this.GetTestMockDefinition();
    var mockError = new TestErrorInfo(code: ErrorResponseCode.BadRequest, message: "Input is invalid.");
    mockData.ActionMocks["Call_External_API"] = new CallExternalAPIActionMock(
        status: TestWorkflowStatus.Failed, 
        error: mockError);

    // ACT: Create UnitTestExecutor instance. Run the workflow with mock data.
    var testRun = await this.TestExecutor
        .Create()
        .RunWorkflowAsync(testMock: mockData).ConfigureAwait(continueOnCapturedContext: false);

    // ASSERT: Confirm successful workflow execution and that the status is 'Succeeded'.
    Assert.IsNotNull(value: testRun);
    Assert.AreEqual(expected: TestWorkflowStatus.Failed, actual: testRun.Status);
}

Hilfsmethoden

Im folgenden Abschnitt werden methoden beschrieben, die von den Beispieltestmethoden verwendet werden. Hilfsmethoden werden unter den Testmethoden in der Klassendefinition angezeigt.

GetTestMockDefinition()

Die folgende Methode lädt die Pseudodefinition aus einer JSON-Datei. Sie können diese Methode bearbeiten, wenn Ihre Simuliertdaten an einem anderen Speicherort oder Format gespeichert sind.

private TestMockDefinition GetTestMockDefinition()
{
    var mockDataPath = Path.Combine(TestExecutor.rootDirectory, "Tests", TestExecutor.logicAppName, 
        TestExecutor.workflow, "<unit-test-name>", "<unit-test-name>-mock.json");
    return JsonConvert.DeserializeObject<TestMockDefinition>(File.ReadAllText(mockDataPath));
}

Callback-Methode

Die folgende Methode generiert dynamisch Simulierte Daten. Der Methodenname variiert je nach dem Namen der simulierten Aktion in den Testmethoden für statische oder dynamische Modelldaten. Sie können diese Methode bearbeiten, um verschiedene simulierte Antworten basierend auf den Testszenarioanforderungen zurückzugeben, oder sie als Vorlage zum Erstellen eigener dynamischer Rückrufmethoden verwenden.

public CallExternalAPIActionMock CallExternalAPIActionMockOutputCallback(TestExecutionContext context)
{
    // Sample mock data: Dynamically change the mocked data for "actionName".
    return new CallExternalAPIActionMock(
        status: TestWorkflowStatus.Succeeded,
        outputs: new CallExternalAPIActionOutput {

            // If this account contains a JObject Body, 
            // set the properties you want here:
            // Body = "something".ToJObject()

        }
    );
}

Erstellen von Komponententests aus Standardworkflowdefinitionen in Azure Logic Apps mit Visual Studio Code

Feedback

War diese Seite hilfreich?

Last updated on 2025-06-09