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

Aplica-se a: Aplicativos Lógicos do Azure (Padrão)

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

Para fluxos de trabalho de aplicativos lógicos padrão, você pode criar testes de unidade usando o Visual Studio Code e a extensão Azure Logic Apps (Standard). Esse recurso permite que você use definições de fluxo de trabalho para criar testes de unidade e adaptá-los a cenários suportados por sua solução de aplicativo lógico - tudo sem precisar de conexões com quaisquer serviços, sistemas ou APIs externos. Essa abordagem permite que você teste seus fluxos de trabalho sem precisar interagir com serviços, sistemas ou APIs externos e oferece 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 do teste de unidade com seu processo de desenvolvimento, garantindo um comportamento consistente e preciso do fluxo de trabalho.

Este guia mostra como criar uma definição de teste de unidade a partir 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 fortemente tipadas para cada operação simulável em seu fluxo de trabalho.

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

Pré-requisitos

• Uma conta Azure e uma assinatura. Se não tiver uma subscrição, inscreva-se numa conta gratuita do Azure.

• Um projeto de aplicativo lógico padrão 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 configuração do Visual Studio Code e a criação de projetos, consulte Criar fluxos de trabalho de aplicativo lógico padrão com o Visual Studio Code.

Limitações e problemas conhecidos

• Esta versão atualmente suporta apenas C# para criar testes de unidade.

• Esta versão não suporta ações não simuladas. Certifique-se de que todas as ações no caminho de execução do fluxo de trabalho são simuladas.

• Esta versão não suporta os seguintes tipos de ação:

  • Ações da conta de integração
  • Ações para codificar e decodificar EDI

Rever os conceitos básicos

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

• 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 do fluxo de trabalho ou ações que dependem de serviços ou sistemas externos.

• Ação 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 testes 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 de aplicativo lógico padrão.

2. No seu projeto, expanda a pasta de definição do 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, classe de teste de unidade e arquivo C#.

   Uma nova pasta chamada Testes agora aparece no espaço de trabalho do projeto. Esta pasta tem a seguinte estrutura:

   

   Pasta ou ficheiro	Descrição
   Tests || <logic-app-name>	Na pasta Tests, uma pasta <logic-app-name> aparece quando se adicionam testes de unidade a um projeto de aplicação lógica.
   Tests || <logic-app-name> ||| <workflow-name>	Na pasta <logic-app-name>, uma pasta <workflow-name> aparece quando se adicionam 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 ficheiro 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 diferentes entradas e saídas com base no valor fornecido para esse parâmetro. Você pode usar essas classes para estender seus 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 ficheiro <unit-test-name>.cs. Use 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 seus cenários de teste específicos.

Revise o arquivo de teste de unidade *.cs

Esta classe de teste de unidade fornece uma estrutura para testar fluxos de trabalho de aplicativos lógicos padrão simulando 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 instancia a TestExecutor classe usando o caminho para o arquivo de configuração de definições de teste. O método é executado antes de cada execução de teste e cria uma nova instância do TestExecutor.

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

Métodos de ensaio por amostragem

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

Teste estático de dados simulados

O método a seguir mostra como usar dados fictícios estáticos para testar seu fluxo de trabalho. Nesse 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 através de métodos de retorno de chamada. Essa abordagem oferece duas opções que geram dados fictícios dinamicamente:

• 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 do 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 sob os métodos de teste na definição de classe.

Método de callback

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

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 padrão em Aplicativos Lógicos do Azure com o Visual Studio Code