Eenheidstests maken van Standard-werkstroomuitvoeringen in Azure Logic Apps met Visual Studio Code

Van toepassing op: Azure Logic Apps (Standard)

Eenheidstests zijn een essentiële praktijk die uw app of oplossing betrouwbaar en nauwkeurig houdt gedurende de levenscyclus van softwareontwikkeling. Met eenheidstests kunt u de belangrijkste onderdelen in uw oplossing efficiënt en systematisch valideren.

Voor werkstromen voor logische apps van Standard kunt u eenheidstests maken met behulp van Visual Studio Code en de Azure Logic Apps-extensie (Standard). Met deze mogelijkheid kunt u eerder uitgevoerde werkstroomuitvoeringen gebruiken om eenheidstests te maken en deze af te stemmen op scenario's die worden ondersteund door uw logische app-oplossing. Deze aanpak biedt de volgende voordelen:

Werkstroomuitvoeringen opnieuw gebruiken om gesimuleerde gegevens te genereren voor specifieke bewerkingen in de werkstroom.

Met deze gegevens kunt u werkstromen testen zonder externe services, systemen of API's aan te roepen. U bespaart tijd en uw werkstroom blijft afgestemd op het werkelijke scenario voor werkstroomuitvoering.
Verbeter de kwaliteit van de werkstroom door potentiële problemen te identificeren en op te lossen voordat u implementeert in andere omgevingen.
Stroomlijn de integratie van eenheidstests met uw ontwikkelproces en zorg voor consistent en nauwkeurig werkstroomgedrag.

In deze handleiding ziet u hoe u een eenheidstestdefinitie maakt op basis van een werkstroomuitvoering. Met deze definitie worden de externe aanroepen van elke werkstroombewerking gesimuleerd zonder de werkstroomlogica te wijzigen. Wanneer u een eenheidstest maakt op basis van een werkstroomuitvoering, krijgt u een eenheidstestproject met twee mappen:

Een map met sterk getypte klassen voor elke gesimuleerde bewerking in uw werkstroom.
Een map voor elke eenheidstestdefinitie, die de volgende bestanden bevat:
- Een JSON-bestand dat de gegenereerde gesimuleerde bewerkingen in uw werkstroom vertegenwoordigt.
- Een C#-bestand met een voorbeeldklasse en methoden die u gebruikt om uw eigen asserties in te stellen, te bevestigen dat de werkstroom werkt zoals verwacht en ervoor te zorgen dat de werkstroom betrouwbaar en voorspelbaar werkt in uw grotere Azure-ecosysteem.

Vereiste voorwaarden

Een Azure-account en -abonnement. Als u nog geen abonnement hebt, meld u dan aan voor een gratis Azure-account.
Een standaard logische app-project in Visual Studio Code dat ten minste één eerder en lokaal uitgevoerde werkstroom bevat voor het maken van een eenheidstest.

Zie Werkstromen voor logische apps maken met Visual Studio Code voor meer informatie over het instellen en maken van projecten in Visual Studio Code.

Beperkingen en bekende problemen

Deze release ondersteunt momenteel alleen C# voor het maken van eenheidstests.
Deze release biedt geen ondersteuning voor niet-gesimuleerde acties. Zorg ervoor dat alle acties in het uitvoeringspad van de werkstroom worden gesimuleerd.
Deze release biedt geen ondersteuning voor de volgende actietypen:
- Acties voor integratieaccounts
- Gegevensmapper-acties
- Aangepaste codeacties
- XML-acties
- Liquide acties
- EDI-acties coderen en decoderen

De basisconcepten bekijken

De volgende lijst bevat eenvoudige maar belangrijke concepten over eenheidstests voor Standaardwerkstromen:

Unittest voor logische app

Een gecontroleerde werkstroomuitvoering die mock-objecten injecteert. Deze objecten vertegenwoordigen de werkstroomtrigger of acties die afhankelijk zijn van externe services of systemen.
Simuleerbare actie

Een werkstroomactie die afhankelijk is van een externe service of systeem. U kunt deze acties converteren naar gesimuleerde acties voor het maken en uitvoeren van eenheidstests.

Een unittest maken vanuit een workflow-uitvoering

Open uw Standaard logica-app-project in Visual Studio Code.
Selecteer op de werkbalk van Visual Studio Code in het menu Uitvoeren de foutopsporing starten. (Toetsenbord: druk op F5)
Ga terug naar het Verkenner-venster . Vouw in uw project de map met werkstroomdefinities uit.
Open het snelmenu workflow.json en selecteer Overzicht.
Selecteer op de overzichtspagina onder Uitvoeringsgeschiedenis de werkstroomuitvoering die u wilt gebruiken voor het maken van een eenheidstest.
Selecteer op de werkbalk Uitvoeringsgeschiedenis de optie Unittest maken uit uitvoering.

Geef een naam op die moet worden gebruikt voor het eenheidstest-, eenheidstestklasse- en C#-bestand.

In het Verkenner-venster wordt een nieuwe projectmap met de naam Tests weergegeven onder de projectmap van uw logische app. De map Tests bevat de volgende mappen en bestanden:

Map of bestand	Beschrijving
`Tests` \|\| <`logic-app-name`>	In de `Tests` map wordt een <`logic-app-name`> map weergegeven wanneer u eenheidstests toevoegt aan een logic app-project.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`>	In de <`logic-app-name`> map wordt een <`workflow-name`> map weergegeven wanneer u eenheidstests voor een werkstroom toevoegt.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`> \|\|\|\| `MockOutputs` < `operation-name-outputs` >\|\|\|\|\| .`cs`	In de <`workflow-name`> map bevat de `MockOutputs` map een C#-bestand (.cs) met sterk getypte klassen voor elke connectorbewerking in de werkstroom. Elke .cs bestandsnaam gebruikt de volgende indeling: < `operation-name` >[`Trigger\\|Action`]`Output.cs` Als een connectorbewerking dynamische contracten heeft, wordt er een klasse weergegeven voor elk dynamisch type. Een dynamisch type verwijst naar een bewerkingsparameter met verschillende invoer- en uitvoerwaarden op basis van de waarde die voor die parameter is opgegeven. U kunt deze klassen gebruiken om uw eenheidstests uit te breiden en nieuwe mocks helemaal zelf te maken.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`> \|\|\|\| <`unit-test-name`> \|\|\|\|\| <`unit-test-name`>`-mock.json` \|\|\|\|\| <`unit-test-name`>`.cs`	In de <`workflow-name`> map bevat de <`unit-test-name`> map de volgende bestanden: - Het <`unit-test-name`>`-mock.json` bestand bevat een JSON-weergave voor de gegenereerde mocks, op basis van de werkstroomuitvoering die de eenheidstest heeft gemaakt. - Het <`unit-test-name`>`.cs` bestand bevat een C#-voorbeeldklasse en -methoden die het *`-mock.json`** bestand gebruiken om resultaten uit te voeren en te bevestigen. U kunt dit bestand bewerken zodat dit overeenkomt met uw specifieke testscenario's.

Controleer het bestand *-mock.json

Dit bestand bevat de volgende hoofdsecties:

`triggerMocks` afdeling

De triggerMocks sectie bevat het gesimuleerde resultaat van de werkstroomtrigger. Deze sectie is vereist om de uitvoering van de werkstroom te starten, zoals wordt weergegeven in het volgende voorbeeld:

{
    "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` afdeling

Voor elke gesimuleerde actie in een werkstroomuitvoering bevat de actionMocks sectie een gesimuleerde actie en garandeert de gecontroleerde uitvoering van de werkstroom.

{
    "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": {}
            }
        }
    }
}

Bekijk het eenheidstestbestand *.cs

Deze unittestklasse biedt een framework voor het testen van standaardwerkstromen in Logic Apps door het mocken van triggers en acties. Met deze klasse kunt u werkstromen testen zonder externe services of API's aan te roepen.

Klassestructuur testen

Een typische eenheidstestklasse maakt gebruik van de volgende structuur:

[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.
}

Methode Setup()

Met deze methode wordt de TestExecutor klasse geïnstitueerd met behulp van het pad naar het configuratiebestand voor testinstellingen. De methode wordt uitgevoerd vóór elke testuitvoering en maakt een nieuw exemplaar van TestExecutor.

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

Voorbeeldtestmethoden

In de volgende sectie worden voorbeeldtestmethoden beschreven die u in uw eenheidstestklasse kunt gebruiken.

Test van statische mockgegevens

De volgende methode laat zien hoe u statische mockgegevens gebruikt om uw werkstroom te testen. In deze methode kunt u de volgende taken uitvoeren:

Stel eigenschapswaarden in voor uw gesimuleerde acties.
Voer de werkstroom uit met de geconfigureerde simulatiegegevens.
Controleer of de uitvoering is geslaagd.

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

Dynamische test van gesimuleerde gegevens

De volgende methode laat zien hoe u dynamische mockgegevens gebruikt met callback-methoden. Deze benadering biedt twee opties waarmee gesimuleerde gegevens dynamisch worden gegenereerd:

Definieer een afzonderlijke callback-methode.
Gebruik een inline lambda-functie.

Met beide benaderingen kunt u dynamische antwoorden maken op basis van de uitvoeringscontext van de eenheidstest.

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

Foutscenario-test

De volgende methode laat zien hoe u foutvoorwaarden test. In deze methode kunt u de volgende taken uitvoeren:

Configureer gesimuleerde acties zodat ze mislukken met specifieke foutcodes en berichten.
Controleer of de werkstroom deze foutvoorwaarden correct verwerkt.

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

Helpermethoden

In de volgende sectie worden methoden beschreven die worden gebruikt door de voorbeeldtestmethoden. Helpermethoden worden weergegeven onder de testmethoden in de klassedefinitie.

GetTestMockDefinition()

Met de volgende methode wordt de mockdefinitie uit een JSON-bestand geladen. U kunt deze methode bewerken als uw mockgegevens zijn opgeslagen op een andere locatie of indeling.

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

Callbackmethode

Met de volgende methode worden gesimuleerde gegevens dynamisch gegenereerd. De naam van de methode varieert op basis van de gesimuleerde actienaam in de testmethoden voor statische of dynamische mockgegevens. U kunt deze methode bewerken om verschillende gesimuleerde antwoorden te retourneren op basis van uw vereisten voor het testscenario of deze als sjabloon gebruiken om uw eigen dynamische callback-methoden te maken.

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

        }
    );
}

Eenheidstests maken van Standard-werkstroomdefinities in Azure Logic Apps met Visual Studio Code

Feedback

Is deze pagina nuttig?

Last updated on 2025-06-09