Criar testes de unidade a partir de definições de fluxo de trabalho Standard nos Aplicativos Lógicos do Azure com o Visual Studio Code

Aplica-se a: Aplicativos Lógicos do Azure (Standard)

O teste de unidade é uma prática essencial que mantém seu aplicativo ou solução confiável e precisa em todo o ciclo de vida de desenvolvimento de software. Os testes de unidade ajudam você a validar de forma eficiente e sistemática os principais componentes em sua solução.

Para fluxos de trabalho do aplicativo Logic Apps Standard, você pode criar testes de unidade usando o Visual Studio Code e a extensão Azure Logic Apps (Standard). Essa funcionalidade permite que você use definições de fluxo de trabalho para criar testes de unidade e adaptá-los a cenários compatíveis com sua solução de aplicativo lógico , tudo sem precisar de conexões com serviços externos, sistemas ou APIs. Essa abordagem permite que você teste seus fluxos de trabalho sem precisar interagir com serviços externos, sistemas ou APIs e fornece os seguintes benefícios:

• Melhore a qualidade do fluxo de trabalho identificando e resolvendo possíveis problemas antes de implantar em outros ambientes.

• Simplifique a integração de teste de unidade com seu processo de desenvolvimento, garantindo um comportamento de fluxo de trabalho consistente e preciso.

Este guia mostra como criar uma definição de teste de unidade de um fluxo de trabalho. Essa definição simula as chamadas externas de cada operação de fluxo de trabalho sem alterar a lógica do fluxo de trabalho. Ao criar um teste de unidade para um fluxo de trabalho, você obtém um projeto de teste de unidade que inclui as seguintes pastas:

• Uma pasta que contém classes tipadas rigidamente para cada operação simulada em seu fluxo de trabalho.

• Uma pasta para cada definição de teste de unidade. Essa pasta inclui um arquivo C# que contém uma classe de exemplo e métodos. Use essa classe e métodos para configurar suas próprias declarações, confirme se o fluxo de trabalho se comporta conforme o esperado e verifique se o fluxo de trabalho se comporta de forma confiável e previsível em seu ecossistema maior do Azure.

Pré-requisitos

• Uma conta e uma assinatura do Azure. Se você não tem uma assinatura, inscreva-se em uma conta gratuita do Azure.

• Um projeto de aplicativo lógico Standard no Visual Studio Code que contém pelo menos uma definição de fluxo de trabalho a ser usada para criar um teste de unidade.

  Para obter mais informações sobre a instalação do Visual Studio Code e a criação de projetos, consulte Criar fluxos de trabalho de aplicativo lógico standard com o Visual Studio Code.

Limitações e problemas conhecidos

• Atualmente, essa versão dá suporte apenas a C# para criar testes de unidade.

• Esta versão não dá suporte a ações não simuladas. Verifique se todas as ações no caminho de execução do fluxo de trabalho são simuladas.

• Esta versão não dá suporte aos seguintes tipos de ação:

  • Ações da conta de integração
  • Ações de codificação e decodificação de EDI

Examinar os conceitos básicos

A lista a seguir inclui conceitos básicos, mas importantes, sobre testes de unidade para fluxos de trabalho Standard:

• Teste de unidade de aplicativo lógico

  Uma execução de fluxo de trabalho controlada que injeta objetos fictícios. Esses objetos representam o gatilho de fluxo de trabalho ou ações que dependem de serviços ou sistemas externos.

• Ação que pode ser simulada

  Uma ação de fluxo de trabalho que depende de um serviço ou sistema externo. Você pode converter essas ações em ações simuladas para criação e execução de teste de unidade.

Criar um teste de unidade a partir de uma definição de fluxo de trabalho

1. No Visual Studio Code, abra seu projeto do aplicativo lógico Standard.

2. Em seu projeto, expanda a pasta de definição de fluxo de trabalho.

3. No menu de atalho do arquivo workflow.json , selecione Abrir Designer.

4. Na barra de ferramentas do designer, selecione Criar teste de unidade.

   

5. Forneça um nome a ser usado para o teste de unidade, a classe de teste de unidade e o arquivo C#.

   Uma nova pasta chamada Testes agora aparece no workspace do projeto. Esta pasta tem a seguinte estrutura:

   

   Pasta ou arquivo	Descrição
   Tests || <logic-app-name>	Na pasta Tests, uma pasta <logic-app-name> é exibida quando você adiciona testes de unidade a um projeto de aplicativo lógico.
   Tests || <logic-app-name> ||| <workflow-name>	Na pasta <logic-app-name>, uma pasta <workflow-name> aparece ao adicionar testes de unidade para um fluxo de trabalho.
   Tests || <logic-app-name> ||| <workflow-name> |||| MockOutputs |||||<operation-name-outputs>.cs	Na pasta <workflow-name>, a pasta MockOutputs contém um arquivo C# (.cs) com classes fortemente tipadas para cada operação de conector no fluxo de trabalho. Cada nome de arquivo .cs usa o seguinte formato: < operation-name >[Trigger\|Action]Output.cs Se uma operação de conector tiver contratos dinâmicos, uma classe será exibida para cada tipo dinâmico. Um tipo dinâmico refere-se a um parâmetro de operação que tem entradas e saídas diferentes com base no valor fornecido para esse parâmetro. Você pode usar essas classes para estender os testes de unidade e criar novas simulações do zero.
   Tests || <logic-app-name> ||| <workflow-name> |||| <unit-test-name> ||||| <unit-test-name>.cs	Na pasta <workflow-name>, a pasta <unit-test-name> contém um arquivo <unit-test-name>.cs. Você usa esse arquivo, que contém uma classe C# de exemplo e métodos, para executar e afirmar resultados. Você pode editar esse arquivo para corresponder aos cenários de teste específicos.

Examinar o arquivo de teste de unidade *.cs

Essa classe de teste de unidade fornece uma estrutura para testar fluxos de trabalho do aplicativo lógico Standard zombando de gatilhos e ações. Essa classe permite testar fluxos de trabalho sem realmente chamar serviços externos ou APIs.

Estrutura de classe de teste

Uma classe de teste de unidade típica usa a seguinte estrutura:

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

Método Setup()

Esse método cria uma instância da classe TestExecutor usando o caminho para o arquivo de configuração de teste. O método é executado antes de cada execução de teste e cria uma nova instância de TestExecutor.

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

Métodos de teste de exemplo

A seção a seguir descreve os métodos de teste de exemplo que você pode usar em sua classe de teste de unidade.

Teste de dados fictícios estáticos

O método a seguir mostra como usar dados fictícios estáticos para testar seu fluxo de trabalho. Neste método, você pode concluir as seguintes tarefas:

• Defina valores de propriedade em suas ações simuladas.
• Execute o fluxo de trabalho com os dados fictícios configurados.
• Confirme se a execução foi bem-sucedida.

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

Teste de dados simulados dinâmicos

O método a seguir mostra como usar dados fictícios dinâmicos com métodos de retorno de chamada. Essa abordagem oferece duas opções que geram dinamicamente dados fictícios:

• Defina um método de retorno de chamada separado.
• Use uma função lambda embutida.

Ambas as abordagens permitem criar respostas dinâmicas com base no contexto de execução de teste de unidade.

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

Métodos auxiliares

A seção a seguir descreve os métodos usados pelos métodos de teste de exemplo. Os métodos auxiliares aparecem nos métodos de teste na definição de classe.

Método de retorno de chamada

O método a seguir gera dinamicamente dados fictícios. O nome do método varia de acordo com o nome da ação simulada nos métodos de teste para dados fictícios estáticos ou dinâmicos. Você pode editar esse método para retornar respostas simuladas diferentes com base nos requisitos do cenário de teste ou usá-lo como um modelo para criar seus próprios métodos dinâmicos de retorno de chamada.

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

        }
    );
}

Conteúdo relacionado

• Criar testes de unidade a partir de execuções de fluxo de trabalho Standard nos Aplicativos Lógicos do Azure com o Visual Studio Code