As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Usar integrações de serviços simuladas para testes no Step Functions Local
Step Functions Local não é suportado
O Step Functions Local não fornece paridade de recursos e não é suportado.
Você pode considerar soluções de terceiros que emulam Step Functions para fins de teste.
No Step Functions Local, você pode testar os caminhos de execução de suas máquinas de estado sem realmente chamar serviços integrados usando integrações de serviços simuladas. Para configurar suas máquinas de estado para usar integrações de serviços simuladas, crie um arquivo de configuração simulado. Nesse arquivo, você define a saída desejada de suas integrações de serviços como respostas simuladas e as execuções que usam essas respostas para simular um caminho de execução como casos de teste.
Ao fornecer o arquivo de configuração simulado ao Step Functions Local, você pode testar as chamadas de integração de serviços executando máquinas de estado que usam as respostas simuladas especificadas nos casos de teste em vez de fazer chamadas reais de integração de serviços.
nota
Se você não especificar respostas de integração de serviços simulados no arquivo de configuração simulado, o Step Functions Local invocará a integração de AWS serviços usando o endpoint que você configurou ao configurar o Step Functions Local. Para obter informações sobre como configurar endpoints para Step Functions Local, consulte Definindo opções de configuração para Step Functions Local.
Este tópico usa vários conceitos definidos na lista a seguir.
Integrações de serviços simulados: refere-se aos estados de tarefas configurados para usar respostas simuladas em vez de realizar chamadas de serviço reais.
Respostas simuladas: refere-se aos dados simulados que os estados da tarefa podem ser configurados para usar.
Casos de teste: refere-se às execuções de máquinas de estado configuradas para usar integrações de serviços simuladas.
Arquivo de configuração simulado - refere-se ao arquivo de configuração simulado que contémJSON, que define integrações de serviços simulados, respostas simuladas e casos de teste.
Configurando integrações de serviços simuladas
Você pode simular qualquer integração de serviços usando o Step Functions Local. No entanto, o Step Functions Local não impõe que os mocks sejam iguais aos reais. APIs Uma tarefa simulada nunca chamará o endpoint do serviço. Se você não especificar uma resposta simulada, uma tarefa tentará chamar os endpoints do serviço. Além disso, o Step Functions Local gerará automaticamente um token de tarefa quando você simular uma tarefa usando o .waitForTaskToken.
Etapa 1: especificar integrações de serviços simulados em um arquivo de configuração simulado
Você pode testar o Step Functions AWS SDK e as integrações de serviços otimizadas usando o Step Functions Local. A imagem a seguir mostra a máquina de estado definida na guia Definição de máquina de estado:
Para fazer isso, você deve criar um arquivo de configuração simulado contendo seções conforme definido em Estrutura do arquivo de configuração simulado.
-
Crie um arquivo chamado
MockConfigFile.jsonpara configurar testes com integrações de serviços simuladas.O exemplo a seguir mostra um arquivo de configuração simulado referenciando uma máquina de estados com dois estados definidos chamados
LambdaStateeSQSState.Você pode executar a definição da máquina de estado
LambdaSQSIntegrationreferenciada no arquivo de configuração simulado usando um dos seguintes casos de teste:-
HappyPath- Este teste simula a saída deLambdaStateeSQSStateusandoMockedLambdaSuccesseMockedSQSSuccessrespectivamente.-
O
LambdaStateretorna o seguinte valor:"0":{ "Return":{ "StatusCode":200, "Payload":{ "StatusCode":200, "body":"Hello from Lambda!" } } } -
O
SQSStateretorna o seguinte valor:"0":{ "Return":{ "MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51", "MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51" } }
-
-
RetryPath- Este teste simula a saída deLambdaStateeSQSStateusandoMockedLambdaRetryeMockedSQSSuccessrespectivamente. Além disso, oLambdaStateestá configurado para realizar quatro tentativas de repetição. As respostas simuladas para essas tentativas são definidas e indexadas no estadoMockedLambdaRetry.-
A tentativa inicial termina com uma falha de tarefa contendo uma causa e uma mensagem de erro, conforme mostrado no exemplo a seguir.
"0":{ "Throw": { "Error": "Lambda.ResourceNotReadyException", "Cause": "Lambda resource is not ready." } } -
A primeira e a segunda tentativas terminam com uma falha de tarefa contendo uma causa e uma mensagem de erro, conforme mostrado no exemplo a seguir.
"1-2":{ "Throw": { "Error": "Lambda.TimeoutException", "Cause": "Lambda timed out." } } -
A terceira tentativa termina com uma tarefa bem-sucedida contendo o resultado do estado da seção Payload na resposta simulada do Lambda.
"3":{ "Return": { "StatusCode": 200, "Payload": { "StatusCode": 200, "body": "Hello from Lambda!" } } }nota
Para estados com uma política de repetição, o Step Functions Local esgotará as tentativas de repetição definidas na política até receber uma resposta bem-sucedida. Isso significa que você deve indicar simulações para novas tentativas com números de tentativas consecutivos e deve abranger todas as tentativas antes de retornar uma resposta bem-sucedida.
Se você não especificar uma resposta simulada para uma tentativa de repetição específica, por exemplo, tentar novamente “3”, a execução da máquina de estado falhará.
-
-
HybridPath- Este teste simula a saída deLambdaState. Depois deLambdaStateser executado com sucesso e receber dados simulados como resposta,SQSStateexecuta uma chamada de serviço real para o recurso especificado na produção.
Para obter informações sobre como iniciar execuções de teste com integrações de serviços simuladas, consulte Etapa 3: executar testes de integração de serviços simulados.
-
Certifique-se de que a estrutura das respostas simuladas esteja em conformidade com a estrutura das respostas de serviço reais que você recebe ao fazer chamadas de serviço integradas. Para obter informações sobre os requisitos estruturais para respostas simuladas, consulte Configurando integrações de serviços simuladas.
No exemplo anterior do arquivo de configuração simulado, as respostas simuladas são definidas em
MockedLambdaSuccesseMockedLambdaRetryestá em conformidade com a estrutura das respostas reais que são retornadas da chamadaHelloFromLambda.Importante
As respostas do serviço AWS podem variar em estrutura entre os diferentes serviços. O Step Functions Local não valida se as estruturas de resposta simuladas estão em conformidade com as estruturas reais de resposta do serviço. Você deve garantir que suas respostas simuladas estejam em conformidade com as respostas reais antes do teste. Para revisar a estrutura das respostas de serviço, você pode realizar as chamadas de serviço reais usando Step Functions ou visualizar a documentação desses serviços.
Etapa 2: forneça ao Step Functions Local o arquivo de configuração simulado
É possível fornecer o arquivo de configuração simulado ao Step Functions Local de uma das seguintes maneiras:
Etapa 3: executar testes de integração de serviços simulados
Depois de criar e fornecer um arquivo de configuração simulado ao Step Functions Local, execute a máquina de estado configurada no arquivo de configuração simulado usando integrações de serviços simuladas. Em seguida, verifique os resultados da execução usando uma API ação.
-
Crie uma máquina de estado com base na definição mencionada anteriormente no arquivo de configuração simulado.
aws stepfunctions create-state-machine \ --endpoint http://localhost:8083 \ --definition "{\"Comment\":\"Thisstatemachineiscalled:LambdaSQSIntegration\",\"StartAt\":\"LambdaState\",\"States\":{\"LambdaState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::lambda:invoke\",\"Parameters\":{\"Payload.$\":\"$\",\"FunctionName\":\"arn:aws:lambda:us-east-1:123456789012:function:HelloWorldFunction\"},\"Retry\":[{\"ErrorEquals\":[\"States.ALL\"],\"IntervalSeconds\":2,\"MaxAttempts\":3,\"BackoffRate\":2}],\"Next\":\"SQSState\"},\"SQSState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::sqs:sendMessage\",\"Parameters\":{\"QueueUrl\":\"https://sqs.us-east-1.amazonaws.com/123456789012/myQueue\",\"MessageBody.$\":\"$\"},\"End\":true}}}" \ --name "LambdaSQSIntegration" --role-arn "arn:aws:iam::123456789012:role/service-role/LambdaSQSIntegration" -
Execute a máquina de estado usando integrações de serviços simuladas.
Para usar o arquivo de configuração simulado, faça uma
StartExecutionAPI chamada em uma máquina de estado configurada no arquivo de configuração simulado. Para fazer isso, anexe o sufixo,#, à máquina ARN de estado usada por.test_nameStartExecutiontest_nameO comando a seguir é um exemplo que usa a máquina de estado
LambdaSQSIntegratione a configuração simulada. Neste exemplo, a máquina de estadoLambdaSQSIntegrationé executada usando o testeHappyPathdefinido em Etapa 1: especificar integrações de serviços simulados em um arquivo de configuração simulado. O testeHappyPathcontém a configuração da execução para lidar com chamadas simuladas de integração de serviços que os estadosLambdaStateeSQSStatefazem usando as respostas de serviço simuladasMockedLambdaSuccesseMockedSQSSuccess.aws stepfunctions start-execution \ --endpoint http://localhost:8083 \ --name executionWithHappyPathMockedServices \ --state-machine arn:aws:states:us-east-1:123456789012:stateMachine:LambdaSQSIntegration#HappyPath Veja a resposta de execução da máquina de estado.
A resposta à chamada
StartExecutionusando um teste simulado de integração de serviços é a mesma resposta à chamadaStartExecutionnormal, que retorna a data de execução ARN e início.Veja a seguir um exemplo de resposta à chamada
StartExecutionusando o teste simulado de integração de serviços:{ "startDate":"2022-01-28T15:03:16.981000-05:00", "executionArn":"arn:aws:states:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices" }Verifique os resultados da execução fazendo uma
GetExecutionHistoryAPI chamadaListExecutionsDescribeExecution, ou.aws stepfunctions get-execution-history \ --endpoint http://localhost:8083 \ --execution-arn arn:aws:states:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServicesO exemplo a seguir demonstra partes de uma resposta à chamada
GetExecutionHistoryusando a execução ARN do exemplo de resposta mostrado na etapa 2. Neste exemplo, a saída deLambdaStateeSQSStatesão os dados simulados definidos no arquivo de configuração simuladoMockedLambdaSuccesseMockedSQSSuccess. Além disso, os dados simulados são usados da mesma forma que os dados retornados pela execução de chamadas reais de integração de serviços seriam usados. Além disso, neste exemplo, a saída deLambdaStateé passada aSQSStatecomo entrada.{ "events": [ ... { "timestamp": "2021-12-02T19:39:48.988000+00:00", "type": "TaskStateEntered", "id": 2, "previousEventId": 0, "stateEnteredEventDetails": { "name": "LambdaState", "input": "{}", "inputDetails": { "truncated": false } } }, ... { "timestamp": "2021-11-25T23:39:10.587000+00:00", "type": "LambdaFunctionSucceeded", "id": 5, "previousEventId": 4, "lambdaFunctionSucceededEventDetails": { "output": "{\"statusCode\":200,\"body\":\"\\\"Hello from Lambda!\\\"\"}", "outputDetails": { "truncated": false } } }, ... "timestamp": "2021-12-02T19:39:49.464000+00:00", "type": "TaskStateEntered", "id": 7, "previousEventId": 6, "stateEnteredEventDetails": { "name": "SQSState", "input": "{\"statusCode\":200,\"body\":\"\\\"Hello from Lambda!\\\"\"}", "inputDetails": { "truncated": false } } }, ... { "timestamp": "2021-11-25T23:39:10.652000+00:00", "type": "TaskSucceeded", "id": 10, "previousEventId": 9, "taskSucceededEventDetails": { "resourceType": "sqs", "resource": "sendMessage", "output": "{\"MD5OfMessageBody\":\"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51\",\"MessageId\":\"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51\"}", "outputDetails": { "truncated": false } } }, ... ] }
Arquivo de configuração para integrações de serviços simulados no Step Functions
Step Functions Local não é suportado
O Step Functions Local não fornece paridade de recursos e não é suportado.
Você pode considerar soluções de terceiros que emulam Step Functions para fins de teste.
Para usar integrações de serviços simuladas, você primeiro deve criar um arquivo de configuração simulado chamado MockConfigFile.json contendo suas configurações simuladas. Em seguida, forneça ao Step Functions Local o arquivo de configuração simulado. Esse arquivo de configuração define casos de teste, que contêm estados simulados que usam respostas simuladas de integração de serviços. A seção a seguir contém informações sobre a estrutura da configuração simulada que inclui os estados simulados e as respostas simuladas:
Estrutura do arquivo de configuração simulado
Uma configuração simulada é um JSON objeto que contém os seguintes campos de nível superior:
-
StateMachines- Os campos desse objeto representam máquinas de estado configuradas para usar integrações de serviços simuladas. -
MockedResponse- Os campos desse objeto representam respostas simuladas para chamadas de integração de serviços.
A seguir está um exemplo de um arquivo de configuração simulado que inclui uma definição StateMachine e MockedResponse.
{
"StateMachines":{
"LambdaSQSIntegration":{
"TestCases":{
"HappyPath":{
"LambdaState":"MockedLambdaSuccess",
"SQSState":"MockedSQSSuccess"
},
"RetryPath":{
"LambdaState":"MockedLambdaRetry",
"SQSState":"MockedSQSSuccess"
},
"HybridPath":{
"LambdaState":"MockedLambdaSuccess"
}
}
}
},
"MockedResponses":{
"MockedLambdaSuccess":{
"0":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
},
"LambdaMockedResourceNotReady":{
"0":{
"Throw":{
"Error":"Lambda.ResourceNotReadyException",
"Cause":"Lambda resource is not ready."
}
}
},
"MockedSQSSuccess":{
"0":{
"Return":{
"MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
"MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
}
}
},
"MockedLambdaRetry":{
"0":{
"Throw":{
"Error":"Lambda.ResourceNotReadyException",
"Cause":"Lambda resource is not ready."
}
},
"1-2":{
"Throw":{
"Error":"Lambda.TimeoutException",
"Cause":"Lambda timed out."
}
},
"3":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
}
}
}Referência de campo de configuração simulada
As seções a seguir explicam os campos de objeto de nível superior que você deve definir em sua configuração simulada.
StateMachines
O objeto StateMachines define quais máquinas de estado usarão integrações de serviços simuladas. A configuração de cada máquina de estado é representada como um campo de nível superior de StateMachines. O nome do campo é o nome da máquina de estado e o valor é um objeto contendo um único campo chamado TestCases, cujos campos representam casos de teste dessa máquina de estado.
A sintaxe a seguir mostra uma máquina de estado com dois casos de teste:
"MyStateMachine": {
"TestCases": {
"HappyPath": {
...
},
"SadPath": {
...
}
}TestCases
Os campos de TestCases representam casos de teste individuais para a máquina de estado. O nome de cada caso de teste deve ser exclusivo por máquina de estado e o valor de cada caso de teste é um objeto que especifica uma resposta simulada a ser usada para estados de tarefas na máquina de estado.
O exemplo a seguir de um TestCase vincula dois estados Task a dois MockedResponses:
"HappyPath": {
"SomeTaskState": "SomeMockedResponse",
"AnotherTaskState": "AnotherMockedResponse"
}MockedResponses
MockedResponses é um objeto que contém vários objetos de resposta simulados com nomes de campo exclusivos. Um objeto de resposta simulada define o resultado bem-sucedido ou a saída de erro para cada invocação de um estado de tarefa simulado. Você especifica o número da invocação usando strings de números inteiros individuais, como “0”, “1”, “2” e “3”, ou um intervalo inclusivo de números inteiros, como “0-1”, “2-3”.
Ao simular uma tarefa, você deve especificar uma resposta simulada para cada invocação. Uma resposta deve conter um único campo chamado Return ou Throw cujo valor seja o resultado ou a saída de erro para a invocação simulada da Tarefa. Se você não especificar uma resposta simulada, a execução da máquina de estado falhará.
A seguir está um exemplo de um MockedResponse com objetos Throw e Return. Neste exemplo, nas primeiras três vezes em que a máquina de estado é executada, a resposta retornada é a especificada em "0-2", e na quarta vez em que a máquina de estado é executada, a resposta retornada é a especificada em "3".
"SomeMockedResponse": {
"0-2": {
"Throw": {
...
}
},
"3": {
"Return": {
...
}
}
}nota
Se você estiver usando um estado Map e quiser garantir respostas previsíveis para o estado Map, defina o valor de maxConcurrency como 1. Se você definir um valor maior que 1, o Step Functions Local executará várias iterações simultaneamente, o que fará com que a ordem geral de execução dos estados nas iterações seja imprevisível. Isso pode ainda fazer com que o Step Functions Local use diferentes respostas simuladas para estados de iteração de uma execução para a próxima.
Return
Return é representado como um campo dos objetos MockedResponse. Ele especifica o resultado bem-sucedido de um estado de tarefa simulado.
Veja a seguir um exemplo de um objeto Return que contém uma resposta simulada para chamar Invoke em uma função do Lambda:
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}Throw
Throw é representado como um campo dos objetos MockedResponse. Ele especifica a saída de erro de uma tarefa com falha. O valor de Throw deve ser um objeto contendo campos Error e Cause com valores de string. Além disso, o valor da string que você especifica no campo Error do MockConfigFile.json deve corresponder aos erros tratados nas seções Retry e Catch da sua máquina de estado.
Veja abaixo um exemplo de um objeto Throw que contém uma resposta simulada para chamar Invoke em uma função do Lambda:
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}