Создание модульных тестов из рабочего процесса "Стандартный" в Azure Logic Apps с помощью Visual Studio Code

Область применения: Azure Logic Apps (стандартная версия)

Модульное тестирование — это важная практика, которая обеспечивает надежность и точность вашего приложения или решения в течение жизненного цикла разработки программного обеспечения. Модульные тесты помогают эффективно и систематически проверять ключевые компоненты в решении.

Для рабочих процессов приложения логики уровня "Стандартный" можно создавать модульные тесты с помощью Visual Studio Code и расширения Azure Logic Apps (standard). Эта возможность позволяет использовать ранее выполняемые рабочие процессы для создания модульных тестов и их адаптации к сценариям, поддерживаемым решением приложения логики. Этот подход обеспечивает следующие преимущества:

Для повторного использования выполнения рабочих процессов с целью создания тестовых данных для конкретных операций в рабочем процессе.

Эти данные позволяют тестировать рабочие процессы без вызова внешних служб, систем или API. Вы экономите время, а рабочий процесс остается в соответствии с фактическим сценарием выполнения рабочего процесса.
Повышение качества рабочего процесса путем выявления и устранения потенциальных проблем перед развертыванием в других средах.
Оптимизируйте интеграцию модульного теста с процессом разработки, обеспечивая согласованное и точное поведение рабочего процесса.

В этом руководстве показано, как создать определение модульного теста из запуска рабочего процесса. Это определение макетирует внешние вызовы из каждой операции рабочего процесса без изменения логики рабочего процесса. При создании модульного теста из запуска рабочего процесса вы получите проект модульного теста, содержащий две папки:

Папка, содержащая строго типизированные классы для каждой макетной операции в рабочем процессе.
Папка для каждого определения модульного теста, включающая следующие файлы:
- JSON-файл, представляющий созданные макетные операции в рабочем процессе.
- Файл C#, который содержит пример класса и методы, используемые для настройки собственных проверок, подтверждения того, что рабочий процесс ведет себя как ожидается, и обеспечения того, чтобы рабочий процесс функционировал стабильно и предсказуемо в вашей более крупной экосистеме Azure.

Предпосылки

Учетная запись и подписка Azure. Если у вас нет подписки, зарегистрируйтесь для бесплатной учетной записи Azure.
Проект логического приложения уровня "Стандарт" в Visual Studio Code, содержащий по крайней мере один рабочий процесс, ранее выполненный на локальном уровне, который можно использовать для создания модульного теста.

Дополнительные сведения о настройке и создании проекта Visual Studio Code см. в статье Создание рабочих процессов логического приложения стандартного типа с помощью Visual Studio Code.

Ограничения и известные проблемы

В настоящее время этот выпуск поддерживает только C# для создания модульных тестов.
Этот выпуск не поддерживает неисключаемые действия. Убедитесь, что все действия в ходе выполнения рабочего процесса имитируются.
Этот выпуск не поддерживает следующие типы действий:
- Действия учетной записи интеграции
- Действия сопоставления данных
- Специальные действия кода
- ДЕЙСТВИЯ XML
- Действия с жидкостью
- Кодирование и декодирование действий EDI

Ознакомьтесь с основными понятиями

В следующем списке содержатся основные понятия, но важные понятия о модульных тестах для стандартных рабочих процессов:

Модульный тест приложения логики

Управляемое выполнение рабочего процесса, которое внедряет макеты объектов. Эти объекты представляют триггер рабочего процесса или действия, зависящие от внешних служб или систем.
Издевательное действие

Действие рабочего процесса, зависящее от внешней службы или системы. Эти действия можно преобразовать в макетные действия для создания и выполнения модульного теста.

Создайте модульный тест на основе запуска рабочего процесса

В Visual Studio Code откройте проект приложения логики "Стандартный".
На панели инструментов Visual Studio Code в меню "Запуск " выберите "Начать отладку". (Клавиатура: нажмите клавишу F5)
Вернитесь в окно обозревателя . В проекте разверните папку определения рабочего процесса.
Откройте контекстное меню workflow.json и выберите "Обзор".
На странице обзора в разделе "Журнал выполнения" выберите рабочий процесс, используемый для создания модульного теста.
На панели инструментов журнала выполнения выберите Создать модульный тест из выполнения.

Укажите имя, используемое для модульного теста, класса модульного теста и файла C#.

В окне обозревателя новая папка проекта с именем Test отображается в папке проекта приложения логики. Папка Test содержит следующие папки и файлы:

Папка или файл	Описание
`Tests` \|\| <`logic-app-name`>	В папке `Tests` появляется папка <`logic-app-name`>, когда добавляете тесты модулей в проект логического приложения.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`>	В папке <`logic-app-name`> появляется папка <`workflow-name`>, когда вы добавляете модульные тесты для рабочего процесса.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`> \|\|\|\| `MockOutputs` < `operation-name-outputs` >\|\|\|\|\|.`cs`	В папке <`workflow-name`>`MockOutputs` папка содержит файл C# (.cs) с строго типизированными классами для каждой операции соединителя в рабочем процессе. Каждое .cs имя файла использует следующий формат: < `operation-name` >[`Trigger\\|Action`]`Output.cs` Если операция соединителя имеет динамические контракты, то для каждого динамического типа отображается класс. Динамический тип относится к параметру операции, который имеет различные входные и выходные данные на основе значения, предоставленного для этого параметра. Эти классы можно использовать для расширения модульных тестов и создания новых макетов с нуля.
`Tests` \|\| <`logic-app-name`> \|\|\| <`workflow-name`> \|\|\|\| <`unit-test-name`> \|\|\|\|\| <`unit-test-name`>`-mock.json` \|\|\|\|\| <`unit-test-name`>`.cs`	В папке <`workflow-name`> папка <`unit-test-name`> содержит следующие файлы: <`unit-test-name`>`-mock.json`— Файл содержит представление JSON для созданных макетов на основе запуска рабочего процесса, создавшего модульный тест. — Файл <`unit-test-name`>`.cs` содержит пример класса C# и методов, которые используют *`-mock.json`** файл для выполнения и утверждения результатов. Этот файл можно изменить в соответствии с конкретными сценариями тестирования.

Просмотрите файл *-mock.json

Этот файл содержит следующие основные разделы:

Раздел `triggerMocks`

В triggerMocks разделе содержатся макетированные результаты триггера рабочего процесса. Этот раздел необходим для запуска выполнения рабочего процесса, как показано в следующем примере:

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

Для каждого имитируемого действия в запуске рабочего процесса раздел actionMocks содержит имитированное действие и гарантирует управляемое выполнение рабочего процесса.

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

Рассмотрите файл модульного теста *.cs

Этот класс тестирования модулей предоставляет средство для тестирования рабочих процессов стандартных приложений логики посредством эмуляции триггеров и действий. Этот класс позволяет тестировать рабочие процессы без фактического вызова внешних служб или API.

Структура тестового класса

Типичный класс модульного теста использует следующую структуру:

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

Этот метод создает экземпляр TestExecutor класса с помощью пути к файлу конфигурации параметров теста. Метод выполняется перед каждым выполнением теста и создает новый экземпляр TestExecutor.

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

Примеры методов тестирования

В следующем разделе описаны примеры методов тестирования, которые можно использовать в классе модульного теста.

Тестирование статических данных макета

В следующем методе показано, как использовать статические макетные данные для тестирования рабочего процесса. В этом методе можно выполнить следующие задачи:

Задайте значения свойств для макетированных действий.
Выполните рабочий процесс с настроенными данными макета.
Убедитесь, что выполнение выполнено успешно.

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

Динамический тест данных макета

В следующем методе показано, как использовать динамические макетные данные с методами обратного вызова. Этот подход предоставляет два варианта динамического создания макетных данных:

Определите отдельный метод обратного вызова.
Используйте встроенную лямбда-функцию.

Оба подхода позволяют создавать динамические ответы на основе контекста выполнения модульного теста.

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

Тест сценария ошибки

В следующем методе показано, как проверить условия сбоя. В этом методе можно выполнить следующие задачи:

Настройте макетированные действия для сбоя с определенными кодами ошибок и сообщениями.
Убедитесь, что рабочий процесс правильно обрабатывает эти условия ошибки.

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

Вспомогательные методы

В следующем разделе описываются методы, используемые примерами методов тестирования. Вспомогательные методы отображаются под методами тестирования в определении класса.

GetTestMockDefinition()

Следующий метод загружает определение макета из JSON-файла. Этот метод можно изменить, если данные макета хранятся в другом расположении или формате.

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

Метод обратного вызова

Следующий метод динамически создает макетные данные. Имя метода зависит от имени измеченного действия в методах тестирования для статических или динамических макетных данных. Этот метод можно изменить, чтобы возвращать различные ответы макета на основе требований тестового сценария или использовать его в качестве шаблона для создания собственных методов динамического обратного вызова.

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

        }
    );
}

Создание модульных тестов из определений стандартных рабочих процессов в Azure Logic Apps с помощью Visual Studio Code

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-06-09