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
**O Step Functions Local não é compatível**
O Step Functions Local **não** fornece paridade de recursos e não é **compatível**.
Considere usar soluções de terceiros que emulam o 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](sfn-local.md#sfn-local-config-options).
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ém JSON, 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 AWS SDK do Step Functions 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:
![\[Exemplo de integração de serviços simulada.\]](http://docs.aws.amazon.com/pt_br/step-functions/latest/dg/images/msi-graph.png)
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](#mock-cfg-struct).
1. Crie um arquivo chamado `MockConfigFile.json` para 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 `LambdaState` e `SQSState`.
------
#### [ Mock configuration file example ]
Veja a seguir um exemplo de um arquivo de configuração simulado que demonstra como simular respostas da [invocação de uma função do Lambda](connect-lambda.md) e do [envio de uma mensagem para o Amazon SQS](connect-sqs.md). Neste exemplo, a máquina de estado [`LambdaSQSIntegration`](#mock-cfg-sm-sect) contém três casos de teste chamados `HappyPath`, `RetryPath` e `HybridPath` que simulam os estados `Task` chamados `LambdaState` e `SQSState`. Esses estados usam as respostas de serviço simuladas `MockedLambdaSuccess`, `MockedSQSSuccess` e `MockedLambdaRetry`. Essas respostas de serviço simuladas são definidas na seção `MockedResponses` do arquivo.
```
{
"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!"
}
}
}
}
}
}
```
------
#### [ State machine definition ]
Veja a seguir um exemplo de uma definição de máquina de estado chamada `LambdaSQSIntegration`, que define dois estados de tarefas de integração de serviços chamados `LambdaState` e `SQSState`. `LambdaState` contém uma política de repetição baseada em `States.ALL`.
```
{
"Comment":"This state machine is called: LambdaSQSIntegration",
"StartAt":"LambdaState",
"States":{
"LambdaState":{
"Type":"Task",
"Resource":"arn:aws:states:::lambda:invoke",
"Parameters":{
"Payload.$":"$",
"FunctionName":"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/account-id/myQueue",
"MessageBody.$":"$"
},
"End": true
}
}
}
```
------
Você pode executar a definição da máquina de estado `LambdaSQSIntegration` referenciada no arquivo de configuração simulado usando um dos seguintes casos de teste:
+ `HappyPath` - Este teste simula a saída de `LambdaState` e `SQSState` usando `MockedLambdaSuccess` e `MockedSQSSuccess` respectivamente.
+ O `LambdaState` retorna o seguinte valor:
```
"0":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
```
+ O `SQSState` retorna o seguinte valor:
```
"0":{
"Return":{
"MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
"MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
}
}
```
+ `RetryPath` - Este teste simula a saída de `LambdaState` e `SQSState` usando `MockedLambdaRetry` e `MockedSQSSuccess` respectivamente. Além disso, o `LambdaState` está configurado para realizar quatro tentativas de repetição. As respostas simuladas para essas tentativas são definidas e indexadas no estado `MockedLambdaRetry`.
+ 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 de `LambdaState`. Depois de `LambdaState` ser executado com sucesso e receber dados simulados como resposta, `SQSState` executa 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](#run-mocked-serv-integ-tests).
1. 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](#mock-resp-struct-req).
No exemplo anterior do arquivo de configuração simulado, as respostas simuladas são definidas em `MockedLambdaSuccess` e `MockedLambdaRetry` está em conformidade com a estrutura das respostas reais que são retornadas da chamada `HelloFromLambda`.
**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:
------
#### [ Docker ]
**nota**
Se você estiver usando a versão Docker do Step Functions Local, poderá fornecer o arquivo de configuração simulado usando somente uma variável de ambiente. Além disso, você deve montar o arquivo de configuração simulado no contêiner do Step Functions Local na inicialização do servidor.
Monte o arquivo de configuração simulado em qualquer diretório dentro do contêiner do Step Functions Local. Em seguida, defina uma variável de ambiente chamada `SFN_MOCK_CONFIG` que contenha o caminho para o arquivo de configuração simulado no contêiner. Esse método permite que o arquivo de configuração simulado tenha qualquer nome, desde que a variável de ambiente contenha o caminho e o nome do arquivo.
O comando a seguir mostra o formato para iniciar a imagem do Docker.
```
docker run -p 8083:8083
--mount type=bind,readonly,source={absolute path to mock config file},destination=/home/StepFunctionsLocal/MockConfigFile.json
-e SFN_MOCK_CONFIG="/home/StepFunctionsLocal/MockConfigFile.json" amazon/aws-stepfunctions-local
```
O comando a seguir mostra o comando para iniciar a imagem do Docker.
```
docker run -p 8083:8083
--mount type=bind,readonly,source=/Users/admin/Desktop/workplace/MockConfigFile.json,destination=/home/StepFunctionsLocal/MockConfigFile.json
-e SFN_MOCK_CONFIG="/home/StepFunctionsLocal/MockConfigFile.json" amazon/aws-stepfunctions-local
```
------
#### [ JAR File ]
Use uma das seguintes maneiras para fornecer o arquivo de configuração simulado ao Step Functions Local:
+ Coloque o arquivo de configuração simulado no mesmo diretório que `Step FunctionsLocal.jar`. Ao usar esse método, você deve nomear o arquivo de configuração simulado `MockConfigFile.json`.
+ Na sessão que executa o Step Functions Local, defina uma variável de ambiente chamada `SFN_MOCK_CONFIG` para o caminho completo do arquivo de configuração simulado. Esse método permite que o arquivo de configuração simulado tenha qualquer nome, desde que a variável de ambiente contenha o caminho e o nome do arquivo. No exemplo a seguir, a variável `SFN_MOCK_CONFIG` é definida para apontar para um arquivo de configuração simulado chamado `EnvSpecifiedMockConfig.json`, localizado no diretório `/home/workspace`.
```
export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
```
**nota**
Se você não fornecer a variável de ambiente `SFN_MOCK_CONFIG` para o Step Functions Local, por padrão, ele tentará ler um arquivo de configuração simulado chamado `MockConfigFile.json` no diretório a partir do qual você iniciou o Step Functions Local.
Se você colocar o arquivo de configuração simulado no mesmo diretório que `Step FunctionsLocal.jar` e definir a variável de ambiente `SFN_MOCK_CONFIG`, o Step Functions Local lerá o arquivo especificado pela variável de ambiente.
------
## 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 ação de API.
1. Crie uma máquina de estado com base na definição mencionada anteriormente no [arquivo de configuração simulado](#create-mock-config-file).
```
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:region:account-id: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/account-id/myQueue\",\"MessageBody.$\":\"$\"},\"End\":true}}}" \
--name "LambdaSQSIntegration" --role-arn "arn:aws:iam::account-id:role/service-role/LambdaSQSIntegration"
```
1. Execute a máquina de estado usando integrações de serviços simuladas.
Para usar o arquivo de configuração simulado, faça uma chamada de API `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` em uma máquina de estado configurada no arquivo de configuração simulado. Para fazer isso, anexe o sufixo, `#test_name`, ao ARN da máquina de estado usado por `StartExecution`. `test_name` é um caso de teste, configurado para a máquina de estado no mesmo arquivo de configuração simulado.
O comando a seguir é um exemplo que usa a máquina de estado `LambdaSQSIntegration` e a configuração simulada. Neste exemplo, a máquina de estado `LambdaSQSIntegration` é executada usando o teste `HappyPath` definido em [Etapa 1: especificar integrações de serviços simulados em um arquivo de configuração simulado](#create-mock-config-file). O teste `HappyPath` contém a configuração da execução para lidar com chamadas simuladas de integração de serviços que os estados `LambdaState` e `SQSState` fazem usando as respostas de serviço simuladas `MockedLambdaSuccess` e `MockedSQSSuccess`.
```
aws stepfunctions start-execution \
--endpoint http://localhost:8083 \
--name executionWithHappyPathMockedServices \
--state-machine arn:aws:states:region:account-id:stateMachine:LambdaSQSIntegration#HappyPath
```
1. Veja a resposta de execução da máquina de estado.
A resposta à chamada `StartExecution` usando um teste simulado de integração de serviços é a mesma resposta à chamada `StartExecution` normal, que retorna o ARN da execução e a data de início.
Veja a seguir um exemplo de resposta à chamada `StartExecution` usando o teste simulado de integração de serviços:
```
{
"startDate":"2022-01-28T15:03:16.981000-05:00",
"executionArn":"arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}
```
1. Verifique os resultados da execução fazendo uma chamada de API `[ListExecutions](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListExecutions.html)`, `[DescribeExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeExecution.html)` ou `[GetExecutionHistory](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetExecutionHistory.html)`.
```
aws stepfunctions get-execution-history \
--endpoint http://localhost:8083 \
--execution-arn arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices
```
O exemplo a seguir demonstra partes de uma resposta à chamada `GetExecutionHistory` usando o ARN de execução do exemplo de resposta mostrado na etapa 2. Neste exemplo, a saída de `LambdaState` e `SQSState` são os dados simulados definidos no [arquivo de configuração simulado](#create-mock-config-file) `MockedLambdaSuccess` e `MockedSQSSuccess`. 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 de `LambdaState` é passada a `SQSState` como 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
**O Step Functions Local não é compatível**
O Step Functions Local **não** fornece paridade de recursos e não é **compatível**.
Considere usar soluções de terceiros que emulam o Step Functions para fins de teste.
Como alternativa ao Step Functions Local, você pode usar a TestState API para testar a unidade da lógica da máquina de estado antes de implantá-la em sua AWS conta. Para obter mais informações, consulte [Teste de máquinas de estado com TestState API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
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 objeto JSON contendo os campos de nível superior a seguir.
+ `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](#mock-cfg-sm-sect)
+ [MockedResponses](#mock-cfg-mckd-resp-sect)
##### 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 [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) 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](concepts-error-handling.md) 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 [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) em uma função do Lambda:
```
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
```