Erstellen von Komponententests aus Standardworkflowdefinitionen 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 Workflowdefinitionen verwenden, um Komponententests zu erstellen und auf Szenarien anzupassen, die von Ihrer Logik-App-Lösung unterstützt werden – alles ohne Verbindungen zu externen Diensten, Systemen oder APIs. Mit diesem Ansatz können Sie Ihre Workflows testen, ohne mit externen Diensten, Systemen oder APIs interagieren zu müssen, und bietet die folgenden Vorteile:

• 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 einem Workflow erstellen. Diese Definition simuliert die externen Aufrufe aus jedem Workflowvorgang, ohne die Workflowlogik zu ändern. Wenn Sie einen Komponententest für einen Workflow erstellen, erhalten Sie ein Komponententestprojekt, das die folgenden 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. Dieser Ordner enthält eine C#-Datei, die eine Beispielklasse und -methoden enthält. Sie verwenden diese Klasse und Methoden, um Ihre eigenen Assertionen einzurichten, zu bestätigen, dass sich der Workflow wie erwartet 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 eine Workflowdefinition enthält, die 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
  • 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 aus einer Workflowdefinition

1. Öffnen Sie in Visual Studio Code Ihr Standard-Logik-App-Projekt.

2. Erweitern Sie im Projekt den Workflowdefinitionsordner.

3. Wählen Sie im Kontextmenü der Datei workflow.json die Option Designer öffnen aus.

4. Wählen Sie auf der Designersymbolleiste " Komponententest erstellen" aus.

   

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

   Ein neuer Ordner mit dem Namen "Tests " wird nun in Ihrem Projektarbeitsbereich angezeigt. Dieser Ordner weist die folgende Struktur auf:

   

   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	In dem <workflow-name>-Ordner enthält der MockOutputs-Ordner eine C#-Datei (.cs) mit stark typisierten Klassen für jeden Connector-Vorgang im Workflow. 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>.cs	Im <workflow-name> Ordner enthält der <unit-test-name> Ordner eine <unit-test-name>.cs Datei. Sie verwenden diese Datei, die eine C#-Beispielklasse und -methoden enthält, um Ergebnisse auszuführen und zu bestätigen. Sie können diese Datei bearbeiten, um Ihren spezifischen Testszenarien zu entsprechen.

Ü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 trigger data.
    var triggerMockOutput = new WhenMessagesAreAvailableInAQueuePeeklockTriggerOutput();
    // Sample that shows how to set the properties for triggerMockOutput
    // triggerMockOutput.Body.Id = "SampleId";
    var triggerMock = new WhenMessagesAreAvailableInAQueuePeeklockTriggerMock(outputs: triggerMockOutput);

    // Generate mock action data.
    var actionMockOutput = new CallExternalAPIActionOutput();
    // Sample that shows how to set the properties for actionMockOutput
    // actionMockOutput.Body.Name = "SampleResource";
    // actionMockOutput.Body.Id = "SampleId";
    var actionMock = new CallExternalAPIActionMock(name: "Call_External_API", outputs: actionMockOutput);

    // ACT: Create the UnitTestExecutor instance. Run the workflow with mock data.
    var testMock = new TestMockDefinition(
        triggerMock: triggerMock,
        actionMocks: new Dictionary<string, ActionMock>()
        {
            {actionMock.Name, actionMock}
        });
    var testRun = await this.TestExecutor
        .Create()
        .RunWorkflowAsync(testMock: testMock).ConfigureAwait(continueOnCapturedContext: false);

    // ASSERT: Confirm successful workflow execution and that the status is 'Succeeded'.
    Assert.IsNotNull(value: testRun);
    Assert.AreEqual(expected: TestWorkflowStatus.Succeeded, actual: te
    stRun.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 trigger data.
    var triggerMockOutput = new WhenMessagesAreAvailableInAQueuePeeklockTriggerOutput();
    // Sample that shows how to set triggerMockOutput properties.
    // triggerMockOutput.Body.Flag = true;
    var triggerMock = new WhenMessagesAreAvailableInAQueuePeeklockTriggerMock(outputs: triggerMockOutput);

    // PREPARE: Generate mock action data.
    // OPTION 1: Define a callback class.
    var actionMock = new CallExternalAPIActionMock(name: "Call_External_API", onGetActionMock: CallExternalAPIActionMockOutputCallback);

    // OPTION 2: Define inline with a lambda function.
    /*var actionMock = 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 the UnitTestExecutor instance. Run the workflow with mock data.
    var testMock = new TestMockDefinition(
        triggerMock: triggerMock,
        actionMocks: new Dictionary<string, ActionMock>()
        {
            {actionMock.Name, actionMock}
        });
    var testRun = await this.TestExecutor
        .Create()
        .RunWorkflowAsync(testMock: testMock).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);
}

Hilfsmethoden

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

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

        }
    );
}

Verwandte Inhalte

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