Tworzenie testów jednostkowych na podstawie standardowych przebiegów przepływu pracy w usłudze Azure Logic Apps za pomocą programu Visual Studio Code

Dotyczy: Azure Logic Apps (Standard)

Testowanie jednostkowe to podstawowa praktyka, która zapewnia niezawodność i dokładność aplikacji lub rozwiązania w całym cyklu tworzenia oprogramowania. Testy jednostkowe pomagają wydajnie i systematycznie weryfikować kluczowe składniki w rozwiązaniu.

W przypadku przepływów pracy aplikacji logiki w wersji standardowej można tworzyć testy jednostkowe przy użyciu programu Visual Studio Code i rozszerzenia Azure Logic Apps (Standard). Ta funkcja umożliwia korzystanie z wcześniej wykonanych przebiegów przepływu pracy w celu tworzenia testów jednostkowych i dostosowywania ich do scenariuszy obsługiwanych przez rozwiązanie aplikacji logiki. Takie podejście zapewnia następujące korzyści:

Wykorzystaj ponownie przebiegi procesów w celu generowania danych testowych dla określonych operacji w procesach.

Te dane umożliwiają testowanie przepływów pracy bez konieczności wywoływania usług zewnętrznych, systemów lub interfejsów API. Oszczędzasz czas, a przepływ pracy pozostaje zgodny z rzeczywistym scenariuszem wykonywania przepływu pracy.
Popraw jakość przepływu pracy, identyfikując i rozwiązując potencjalne problemy przed wdrożeniem w innych środowiskach.
Usprawnij integrację testów jednostkowych z procesem programowania, zapewniając spójne i dokładne zachowanie przepływu pracy.

W tym przewodniku pokazano, jak utworzyć definicję testu jednostkowego na podstawie przebiegu przepływu pracy. Ta definicja symuluje wywołania zewnętrzne dla każdej operacji w przepływie pracy, bez zmiany logiki przepływu pracy. Podczas tworzenia testu jednostkowego na podstawie przebiegu przepływu pracy uzyskasz projekt testu jednostkowego zawierający dwa foldery:

Folder, który zawiera silnie typizowane klasy dla każdej pozornej operacji w przepływie pracy.
Folder dla każdej definicji testu jednostkowego, który zawiera następujące pliki:
- Plik JSON przedstawiający symulowane operacje wygenerowane w przepływie pracy.
- Plik w języku C# zawierający przykładową klasę i metody, które możesz wykorzystać do konfigurowania własnych warunków sprawdzających, potwierdzania, że przepływ pracy przebiega zgodnie z oczekiwaniami, oraz zapewnienia, że działa niezawodnie i przewidywalnie w szerszym ekosystemie platformy Azure.

Wymagania wstępne

Konto i subskrypcja platformy Azure. Jeśli nie masz subskrypcji, utwórz bezpłatne konto platformy Azure.
Projekt standardowej aplikacji logiki w programie Visual Studio Code zawierający co najmniej jeden wcześniej i lokalnie wykonany przepływ pracy do użycia do tworzenia testu jednostkowego.

Aby uzyskać więcej informacji na temat konfigurowania i tworzenia projektu programu Visual Studio Code, zobacz Create Standard logic app workflows with Visual Studio Code (Tworzenie standardowych przepływów pracy aplikacji logiki za pomocą programu Visual Studio Code).

Ograniczenia i znane problemy

Ta wersja obsługuje obecnie tylko język C# do tworzenia testów jednostkowych.
Ta wersja nie obsługuje nieśmiewionych akcji. Upewnij się, że wszystkie akcje w ścieżce wykonywania przepływu pracy są symulowane.
Ta wersja nie obsługuje następujących typów akcji:
- Akcje konta integracji
- Akcje mapowania danych
- Niestandardowe akcje kodu
- Akcje XML
- Akcje płynne
- Akcje kodowania i dekodowania EDI

Zapoznaj się z podstawowymi pojęciami

Poniższa lista zawiera podstawowe, ale ważne pojęcia dotyczące testów jednostkowych dla standardowych przepływów pracy:

Test jednostkowy aplikacji logiki

Kontrolowana realizacja przepływu pracy, która wprowadza obiekty symulowane. Te obiekty reprezentują wyzwalacz przepływu pracy lub akcje zależne od usług zewnętrznych lub systemów.
Akcja możliwa do symulacji

Akcja przepływu pracy, która zależy od usługi zewnętrznej lub systemu. Możesz przekonwertować te akcje na zasymulowane akcje na potrzeby tworzenia i wykonywania testów jednostkowych.

Tworzenie testu jednostkowego na podstawie przebiegu przepływu pracy

W programie Visual Studio Code otwórz projekt standardowej aplikacji logiki.
Na pasku narzędzi programu Visual Studio Code z menu Uruchom wybierz pozycję Rozpocznij debugowanie. (Klawiatura: Naciśnij F5)
Wróć do okna Eksploratora . W projekcie rozwiń folder definicji przepływu pracy.
Otwórz menu skrótów workflow.json i wybierz pozycję Przegląd.
Na stronie przeglądu w obszarze Historia uruchamiania wybierz przebieg przepływu pracy, który ma zostać użyty do utworzenia testu jednostkowego.
Na pasku narzędzi historii uruchamiania wybierz pozycję Utwórz test jednostkowy z przebiegu.

Podaj nazwę, która ma być używana dla testu jednostkowego, klasy testów jednostkowych i pliku C#.

W oknie Eksplorator zostanie wyświetlony nowy folder projektu o nazwie Testy w folderze projektu aplikacji logiki. Folder Tests zawiera następujące foldery i pliki:

Folder lub plik	Opis
`Tests` \|\| <`logic-app-name`>	W folderze `Tests` pojawi się folder <`logic-app-name`>, gdy dodasz testy jednostkowe do projektu aplikacji logiki.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`>	W folderze <`logic-app-name`> pojawia się folder <`workflow-name`> podczas dodawania testów jednostkowych dla przepływu pracy.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`> \|\|\|\| `MockOutputs` \|\|\|\|\|<`operation-name-outputs`>.`cs`	W folderze <`workflow-name`> folder `MockOutputs` zawiera plik C# (.cs) z klasami silnie typizowanymi dla każdej operacji łącznika w przepływie pracy. Każda nazwa pliku .cs ma następujący format: < `operation-name` >[`Trigger\\|Action`]`Output.cs` Jeśli operacja łącznika zawiera kontrakty dynamiczne, dla każdego typu dynamicznego zostanie wyświetlona klasa. Typ dynamiczny odnosi się do parametru operacji, który ma różne dane wejściowe i wyjściowe na podstawie wartości podanej dla tego parametru. Możesz użyć tych klas, aby rozszerzyć testy jednostkowe i utworzyć nowe makiety od podstaw.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`> \|\|\|\| <`unit-test-name`> \|\|\|\|\| <`unit-test-name`>`-mock.json` \|\|\|\|\| <`unit-test-name`>`.cs`	W folderze <`workflow-name`> folder <`unit-test-name`> zawiera następujące pliki: — Plik <`unit-test-name`>`-mock.json` zawiera reprezentację JSON dla wygenerowanych mocków, opartą na przebiegu przepływu pracy, który utworzył test jednostkowy. — Plik <`unit-test-name`>`.cs` zawiera przykładową klasę i metody języka C#, które używają *`-mock.json`** pliku do uruchamiania i potwierdzania wyników. Możesz edytować ten plik, aby był zgodny z konkretnymi scenariuszami testowymi.

Przejrzyj plik *-mock.json

Ten plik zawiera następujące główne sekcje:

`triggerMocks` sekcja

Sekcja triggerMocks zawiera symulowany wynik wyzwalacza przepływu pracy. Ta sekcja jest wymagana do uruchomienia wykonywania przepływu pracy, jak pokazano w poniższym przykładzie:

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

Dla każdej pozornej akcji w przebiegu actionMocks przepływu pracy sekcja zawiera pozorowaną akcję i gwarantuje kontrolowane wykonywanie przepływu pracy.

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

Przejrzyj plik testów jednostkowych *.cs

Ta klasa testów jednostkowych udostępnia platformę do testowania standardowych przepływów pracy aplikacji Logic App poprzez pozorowanie wyzwalaczy i akcji. Ta klasa umożliwia testowanie przepływów pracy bez faktycznego wywoływania usług zewnętrznych ani interfejsów API.

Struktura klas testowych

Typowa klasa testu jednostkowego używa następującej struktury:

[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(), metoda

Metoda ta tworzy wystąpienie klasy TestExecutor, wykorzystując ścieżkę do pliku konfiguracji ustawień testu. Metoda jest uruchamiana przed każdym wykonaniem testu i tworzy nowe wystąpienie klasy TestExecutor.

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

Przykładowe metody testowania

W poniższej sekcji opisano przykładowe metody testowania, których można użyć w klasie testów jednostkowych.

Statyczny test danych próbnych

Poniższa metoda pokazuje, jak używać statycznych pozornych danych do testowania przepływu pracy. W tej metodzie można wykonać następujące zadania:

Ustaw wartości właściwości na symulowane akcje.
Wykonaj przepływ pracy z skonfigurowanymi testowymi danymi.
Upewnij się, że wykonanie zakończyło się pomyślnie.

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

Dynamiczny pozorny test danych

Poniższa metoda pokazuje, jak używać dynamicznych pozornych danych z metodami wywołania zwrotnego. To podejście zapewnia dwie opcje, które dynamicznie generują pozorne dane:

Zdefiniuj oddzielną metodę wywołania zwrotnego.
Użyj wbudowanej funkcji lambda.

Obie metody umożliwiają tworzenie odpowiedzi dynamicznych na podstawie kontekstu wykonywania testów jednostkowych.

[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 scenariusza błędu

Poniższa metoda pokazuje, jak przetestować sytuacje niepowodzeń. W tej metodzie można wykonać następujące zadania:

Skonfiguruj wyśmiewane akcje, aby zakończyć się niepowodzeniem z określonymi kodami błędów i komunikatami.
Upewnij się, że proces prawidłowo obsługuje te sytuacje błędów.

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

Metody pomocnicze

W poniższej sekcji opisano metody używane przez przykładowe metody testowania. Metody pomocnika znajdują się poniżej metod testowych w definicji klasy.

GetTestMockDefinition()

Poniższa metoda ładuje pozorną definicję z pliku JSON. Tę metodę można edytować, jeśli dane makiety są przechowywane w innej lokalizacji lub formacie.

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

Metoda wywołania zwrotnego

Poniższa metoda dynamicznie generuje pozorne dane. Nazwa metody różni się w zależności od nazwy symulowanej akcji w metodach testowych dla danych statycznych lub dynamicznych symulacji. Tę metodę można edytować, aby zwracać różne pozorne odpowiedzi na podstawie wymagań scenariusza testowego lub użyć jej jako szablonu, aby utworzyć własne metody dynamicznego wywołania zwrotnego.

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

        }
    );
}

Tworzenie testów jednostkowych na podstawie standardowych definicji przepływu pracy w usłudze Azure Logic Apps za pomocą programu Visual Studio Code

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-06-09