O blog da AWS

Acelere o desenvolvimento de fluxos de trabalho com testes locais aprimorados no AWS Step Functions

Por Donnie Prakoso, Principal Developer Advocate na Amazon Web Services.

Hoje, estou animado em anunciar capacidades aprimoradas de testes locais para o AWS Step Functions através da API TestState, nossa API de testes.

Essas melhorias estão disponíveis através da API, para que você possa construir suítes de testes automatizados que validam suas definições de fluxo de trabalho localmente em suas máquinas de desenvolvimento, testar padrões de tratamento de erros, transformações de dados e simular integrações de serviços usando seus frameworks de teste preferidos. Este lançamento introduz uma abordagem baseada em API para testes unitários locais, fornecendo acesso programático a capacidades abrangentes de testes sem implantar na Amazon Web Services (AWS).

Existem três capacidades principais introduzidas nesta API TestState aprimorada:

  • Suporte a simulação (mocking) – Simule saídas e erros de estados sem invocar serviços downstream, permitindo testes unitários verdadeiros da lógica de máquina de estados. TestState valida respostas simuladas contra modelos de API da AWS com três modos de validação: STRICT (este é o padrão e valida todos os campos obrigatórios), PRESENT (valida tipos e nomes de campos) e NONE (sem validação), fornecendo testes de alta fidelidade.
  • Suporte para todos os tipos de estados – Todos os tipos de estados, incluindo estados avançados como estados Map (inline e distribuídos), estados Parallel, estados Task baseados em atividades, padrões de integração de serviço .sync e padrões de integração de serviço .waitForTaskToken, agora podem ser testados. Isso significa que você pode usar a API TestState em toda a sua definição de fluxo de trabalho e escrever testes unitários para verificar a lógica de fluxo de controle, incluindo transições de estado, tratamento de erros e transformações de dados.
  • Testando estados individuais – Teste estados específicos dentro de uma definição completa de máquina de estados usando o novo parâmetro stateName. Você pode fornecer a definição completa da máquina de estados uma vez e testar cada estado individualmente por nome. Você pode controlar o contexto de execução para testar tentativas de retry específicas, posições de iteração de Map e cenários de erro.

Começando com o TestState aprimorado

Deixe-me guiá-lo através dessas novas capacidades no TestState aprimorado.

Cenário 1: Simular resultados bem-sucedidos

A primeira capacidade é o suporte a simulação, que você pode usar para testar sua lógica de fluxo de trabalho sem invocar serviços AWS reais ou até mesmo requisições HTTP externas. Você pode simular respostas de serviços para testes unitários rápidos ou testar com serviços AWS reais para testes de integração. Ao usar respostas simuladas, você não precisa de permissões do AWS Identity and Access Management (IAM).

Aqui está como simular uma resposta bem-sucedida de função AWS Lambda:

aws stepfunctions test-state --region us-east-1 \
--definition '{
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": {"FunctionName": "process-order"},
  "End": true
}' \
--mock '{"result":"{\"orderId\":\"12345\",\"status\":\"processed\"}"}' \
--inspection-level DEBUG

Este comando testa um estado de invocação Lambda sem realmente chamar a função. TestState valida sua resposta simulada contra o modelo de API do serviço Lambda para que seus dados de teste correspondam ao que o serviço real retornaria.

A resposta mostra a execução bem-sucedida com dados de inspeção detalhados (ao usar o nível de inspeção DEBUG):

{
    "output": "{\"orderId\":\"12345\",\"status\":\"processed\"}",
    "inspectionData": {
        "input": "{}",
        "afterInputPath": "{}",
        "afterParameters": "{\"FunctionName\":\"process-order\"}",
        "result": "{\"orderId\":\"12345\",\"status\":\"processed\"}",
        "afterResultSelector": "{\"orderId\":\"12345\",\"status\":\"processed\"}",
        "afterResultPath": "{\"orderId\":\"12345\",\"status\":\"processed\"}"
    },
    "status": "SUCCEEDED"
}

Quando você especifica uma resposta simulada, TestState a valida contra o modelo de API do serviço AWS para que seus dados simulados estejam em conformidade com o esquema esperado, mantendo testes de alta fidelidade sem exigir chamadas reais de serviços AWS.

Cenário 2: Simular condições de erro

Você também pode simular condições de erro para testar sua lógica de tratamento de erros:

aws stepfunctions test-state --region us-east-1 \
--definition '{
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": {"FunctionName": "process-order"},
  "End": true
}' \
--mock '{"errorOutput":{"error":"Lambda.ServiceException","cause":"Function failed"}}' \
--inspection-level DEBUG

Isso simula uma exceção de serviço Lambda para que você possa verificar como sua máquina de estados lida com falhas sem acionar erros reais em seu ambiente AWS.

A resposta mostra a execução falhada com detalhes do erro:

{
    "error": "Lambda.ServiceException",
    "cause": "Function failed",
    "inspectionData": {
        "input": "{}",
        "afterInputPath": "{}",
        "afterParameters": "{\"FunctionName\":\"process-order\"}"
    },
    "status": "FAILED"
}

Cenário 3: Testar estados Map

A segunda capacidade adiciona suporte para tipos de estados anteriormente não suportados. Aqui está como testar um estado Distributed Map:

aws stepfunctions test-state --region us-east-1 \
--definition '{
  "Type": "Map",
  "ItemProcessor": {
    "ProcessorConfig": {"Mode": "DISTRIBUTED", "ExecutionType": "STANDARD"},
    "StartAt": "ProcessItem",
    "States": {
      "ProcessItem": {
        "Type": "Task", 
        "Resource": "arn:aws:states:::lambda:invoke",
        "Parameters": {"FunctionName": "process-item"},
        "End": true
      }
    }
  },
  "End": true
}' \
--input '[{"itemId":1},{"itemId":2}]' \
--mock '{"result":"[{\"itemId\":1,\"status\":\"processed\"},{\"itemId\":2,\"status\":\"processed\"}]"}' \
--inspection-level DEBUG

O resultado simulado representa a saída completa do processamento de múltiplos itens. Neste caso, o array simulado deve corresponder ao formato de saída esperado do estado Map.

A resposta mostra o processamento bem-sucedido da entrada de array:

{
    "output": "[{\"itemId\":1,\"status\":\"processed\"},{\"itemId\":2,\"status\":\"processed\"}]",
    "inspectionData": {
        "input": "[{\"itemId\":1},{\"itemId\":2}]",
        "afterInputPath": "[{\"itemId\":1},{\"itemId\":2}]",
        "afterResultSelector": "[{\"itemId\":1,\"status\":\"processed\"},{\"itemId\":2,\"status\":\"processed\"}]",
        "afterResultPath": "[{\"itemId\":1,\"status\":\"processed\"},{\"itemId\":2,\"status\":\"processed\"}]"
    },
    "status": "SUCCEEDED"
}

Cenário 4: Testar estados Parallel

Da mesma forma, você pode testar estados Parallel que executam múltiplos ramos simultaneamente:

aws stepfunctions test-state --region us-east-1 \
--definition '{
  "Type": "Parallel",
  "Branches": [
    {"StartAt": "Branch1", "States": {"Branch1": {"Type": "Pass", "End": true}}},
    {"StartAt": "Branch2", "States": {"Branch2": {"Type": "Pass", "End": true}}}
  ],
  "End": true
}' \
--mock '{"result":"[{\"branch1\":\"data1\"},{\"branch2\":\"data2\"}]"}' \
--inspection-level DEBUG

O resultado simulado deve ser um array com um elemento por ramo. Ao usar TestState, sua estrutura de dados simulados corresponde ao que uma execução real de estado Parallel produziria.

A resposta mostra os resultados da execução paralela:

{
    "output": "[{\"branch1\":\"data1\"},{\"branch2\":\"data2\"}]",
    "inspectionData": {
        "input": "{}",
        "afterResultSelector": "[{\"branch1\":\"data1\"},{\"branch2\":\"data2\"}]",
        "afterResultPath": "[{\"branch1\":\"data1\"},{\"branch2\":\"data2\"}]"
    },
    "status": "SUCCEEDED"
}

Cenário 5: Testar estados individuais dentro de fluxos de trabalho completos

Você pode testar estados específicos dentro de uma definição completa de máquina de estados usando o parâmetro stateName. Aqui está um exemplo testando um único estado, embora você normalmente forneceria sua definição completa de fluxo de trabalho e especificaria qual estado testar:

aws stepfunctions test-state --region us-east-1 \
--definition '{
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": {"FunctionName": "validate-order"},
  "End": true
}' \
--input '{"orderId":"12345","amount":99.99}' \
--mock '{"result":"{\"orderId\":\"12345\",\"validated\":true}"}' \
--inspection-level DEBUG

Isso testa um estado de invocação Lambda com dados de entrada específicos, mostrando como TestState processa a entrada e a transforma através da execução do estado.

A resposta mostra o processamento detalhado de entrada e validação:

{
    "output": "{\"orderId\":\"12345\",\"validated\":true}",
    "inspectionData": {
        "input": "{\"orderId\":\"12345\",\"amount\":99.99}",
        "afterInputPath": "{\"orderId\":\"12345\",\"amount\":99.99}",
        "afterParameters": "{\"FunctionName\":\"validate-order\"}",
        "result": "{\"orderId\":\"12345\",\"validated\":true}",
        "afterResultSelector": "{\"orderId\":\"12345\",\"validated\":true}",
        "afterResultPath": "{\"orderId\":\"12345\",\"validated\":true}"
    },
    "status": "SUCCEEDED"
}

Essas melhorias trazem a experiência familiar de desenvolvimento local para fluxos de trabalho do Step Functions, ajudando-me a obter feedback instantâneo sobre mudanças antes de implantar na minha conta AWS. Posso escrever suítes de testes automatizados para validar todos os recursos do Step Functions com a mesma confiabilidade da execução na nuvem, fornecendo confiança de que meus fluxos de trabalho funcionarão conforme esperado quando implantados.

Coisas para saber

Aqui estão pontos importantes a observar:

  • Disponibilidade – As capacidades aprimoradas do TestState estão disponíveis em todas as Regiões AWS onde o Step Functions é suportado.
  • Preços – As chamadas da API TestState estão incluídas no AWS Step Functions sem custo adicional.
  • Compatibilidade de frameworks – TestState funciona com qualquer framework de teste que possa fazer requisições HTTP, incluindo Jest, pytest, JUnit e outros. Você pode escrever suítes de testes que validam seus fluxos de trabalho automaticamente em seu pipeline de integração contínua e entrega contínua (CI/CD) antes da implantação.
  • Suporte a recursos – O TestState aprimorado suporta todos os recursos do Step Functions, incluindo Distributed Map, estados Parallel, tratamento de erros e expressões JSONata.
  • Documentação – Para opções detalhadas para diferentes configurações, consulte a documentação do TestState e a referência da API para o modelo de requisição e resposta atualizado.

Comece hoje com testes locais aprimorados integrando TestState em seu fluxo de trabalho de desenvolvimento.

Boa construção!

— Donnie

Donnie Prakoso

Donnie Prakoso

Donnie Prakoso é engenheiro de software, barista autoproclamado e Principal Developer Advocate na AWS. Com mais de 17 anos de experiência na indústria de tecnologia, desde telecomunicações, bancos até startups. Ele agora está focado em ajudar os desenvolvedores a entender variedades de tecnologia para transformar suas ideias em execução. Ele ama café e qualquer discussão sobre qualquer tópico, desde microsserviços até AI / ML.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autor

Donnie Prakoso

Donnie Prakoso é um engenheiro de software, barista auto proclamado e principal developer advocate na AWS.

Tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem.
https://www.linkedin.com/in/danielabib/
Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Atualmente está habilitando empresas do ramo de ISV (Independent Software Vendors) simplificando a operação na nuvem e otimizando os custos em cloud. Sua área de interesse são tecnologias serverless.
https://www.linkedin.com/in/nicolastarzia

step-functions, serverless, local-testing, developer-tools