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

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

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

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

• Повышение качества рабочего процесса путем выявления и устранения потенциальных проблем перед развертыванием в других средах.

• Оптимизируйте интеграцию модульного теста с процессом разработки, обеспечивая согласованное и точное поведение рабочего процесса.

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

• Папка, содержащая строго типизированные классы для каждой макетной операции в рабочем процессе.

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

Предпосылки

• Учетная запись и подписка Azure. Если у вас нет подписки, зарегистрируйтесь для бесплатной учетной записи Azure.

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

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

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

• В настоящее время этот выпуск поддерживает только C# для создания модульных тестов.

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

• Этот выпуск не поддерживает следующие типы действий:

  • Действия учетной записи интеграции
  • Кодирование и декодирование действий EDI

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

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

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

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

• Издевательное действие

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

Создание модульного теста из определения рабочего процесса

1. В Visual Studio Code откройте проект приложения логики "Стандартный".

2. В проекте разверните папку определения рабочего процесса.

3. В контекстном меню файла workflow.json выберите "Открыть конструктор".

4. На панели инструментов конструктора выберите "Создать модульный тест".

   

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

   Новая папка с именем 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>.cs	В папке <workflow-name> находится папка <unit-test-name>, которая содержит файл <unit-test-name>.cs. Этот файл содержит пример класса и методов C# для выполнения и утверждения результатов. Этот файл можно изменить в соответствии с конкретными сценариями тестирования.

Рассмотрите файл модульного теста *.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 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);
}

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

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

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

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

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

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

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

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

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

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